Skip to content

Platform Identity IDs — User ID, Member ID, Attendee ID

Audience: Developers, Integrators, Support, QA, Show Admins Apps: OpenStackID (FNid) · summit-api · Registration / Show Admin

A plain-language guide to the different identifiers a person has across the platform and how they relate — so you never again wonder "is this a user id or a member id?" (They are not the same number.)

The short version

ID Lives in Identifies Scope Example
User ID — a.k.a. OpenStackID uid, OIDC sub, token user_id OpenStackID / FNid the login identity (one per person) platform (identity provider) 4
Member ID (member_id) summit-api the person as a summit-api member platform (spans all shows) 1
Attendee ID summit-api the person at one specific summit per-show 73185
Ticket (id / number) summit-api a registration ticket per-show 86470 / TICKET_…
Badge (qr_code) summit-api the scannable badge on a ticket per-show BADGE_…\|TICKET_…\|email\|name
Order (id / number) summit-api a purchase that groups tickets per-show ORDER_…

How they relate

OpenStackID User  (User ID)
      │   one-to-one, linked by  Member.user_external_id == User ID   (a link, NOT equal numbers)
      ▼
summit-api Member  (member_id)          ← platform identity; connections, favorites, my-schedule key on this
      │   one member → many attendees (one per summit the person registers for)
      ▼
Attendee  (attendee id  + member_id + summit_id)   ← per-show identity; check-in keys on this
      │   one attendee → one or more tickets
      ▼
Ticket  (id, number)  ── has ──▶  Badge  (qr_code)
  • User ↔ Member is one-to-one, but the two id numbers differ. summit-api's Member.user_external_id stores the person's OpenStackID User ID — that field is the link, not an equality.
  • Member → Attendees: a member has one Attendee record per summit they register for. Connections belong to the member (they resurface at the next show); the attendee is the per-show presence.
  • Attendee → Tickets → Badge: an attendee holds one or more tickets; each ticket has a badge with the QR code used for check-in and networking scans.

⚠️ The #1 gotcha: User ID ≠ Member ID

This is the mistake that repeatedly costs hours. They are different numbers and only coincided for a few very old accounts by luck.

  • token.user_id (from OAuth2 token introspection) and the OIDC sub claim are the OpenStackID User ID.
  • summit-api's member_id is a separate id.
  • Example: a person with User ID 4 may be member_id 1. Newer accounts show it starkly — e.g. User ID 1712 maps to member_id 120309.

To get the member_id from a token (never assume it equals the User ID): - With the user's token → GET /api/v1/members/me returns the Member (id = member_id, user_external_id = the User ID). - With service credentials → the members "by external id" lookup maps a User ID → the Member.

Server-side code that needs a member_id must resolve it. Passing token.user_id where a member_id is expected fails silently — e.g. an attendance or connection lookup returns "no record", because it's comparing a User ID against member_ids.

Where you'll see each one

  • OAuth token / token_info / OIDC userinfo → user_id / sub = User ID.
  • GET /api/v1/members/me → id = member_id; user_external_id = the User ID (the link between them).
  • GET /summits/{id}/attendees → each row has id = attendee id, member_id = the member link, and tickets[] (→ ticket.badge.qr_code). Attendance filters use member_id, not User ID.
  • Show Admin → Attendees list → the "Id" column is the attendee id; the "Member" field links the Member.
  • Badge QR → BADGE_<summit-slug>|TICKET_<number>|email|name in plaintext when the show has badge encryption off, or an AES-encrypted blob when on. It resolves to an attendee/member via summit-api.

Practical rules

  • Platform-level features (connections, favorites, my-schedule) key on member_id.
  • Per-show features (attendee record, tickets, badge, check-in) key on the Attendee (member × summit).
  • Server-side: resolve the token → member_id once (via /members/me or the by-external-id lookup) and use that; never pass the raw token.user_id where a member_id is expected.
  • Adding an attendee "by email" in Show Admin can create a new summit-api Member if the email isn't matched to the existing one → duplicate members for one person. Prefer selecting the existing Member, so the attendee links to the same member_id the app authenticates as.