Identity and IDs

The Partner API is built around IDs that you own. Meshi stores mappings internally, but partner responses expose your IDs rather than Meshi internal UUIDs.

Partner-Owned ID Model

You choose these IDs:

Resource	Field
Event	event_id
Session	session_id
Attendee	attendee_id
Generic ID map entry	kind + partner_id

Use stable IDs from your source system. Do not generate a fresh ID each time you retry a create; that creates a different logical object.

ID Validation

Field	Pattern	Notes
kind	^[A-Za-z][A-Za-z0-9_-]{0,63}$	1-64 characters; starts with a letter.
partner_id, event_id, session_id, attendee_id	^[A-Za-z0-9][A-Za-z0-9._:-]{0,127}$	1-128 characters; letters, digits, ., _, :, and -.

Invalid kinds return 400 INVALID_PARTNER_KIND. Invalid IDs return 400 INVALID_PARTNER_ID.

Org Scoping

The org is derived from your API key. Every lookup is scoped to that org:

1. You submit a partner ID.
2. Meshi resolves it to the mapped internal record for your org.
3. Meshi checks access and visibility.
4. Meshi returns data using partner-facing IDs.

An ID that is valid in another org but not mapped in your org returns a not-found error rather than cross-org data.

Confirm an ID Mapping

Use GET /id-map/:kind/:partner_id to check whether an ID is mapped.

curl -sS "$MESHI_BASE/id-map/attendee/att-1001" \
  -H "Authorization: Bearer $MESHI_KEY"

Mapped response:

{
  "kind": "attendee",
  "partner_id": "att-1001",
  "mapped": true,
  "correlation_id": "<CORRELATION_ID>"
}

Unmapped IDs return 404 PARTNER_ID_NOT_FOUND.

Conflict Semantics

Creating a resource with an already-mapped ID returns 409 PARTNER_ID_CONFLICT. In an idempotent integration, treat that as “already provisioned” only after fetching the resource and confirming it is the same logical object.

Identity Reviews

Enrichment can produce identity ambiguity. Open reviews appear in either the org-wide queue or the event-scoped queue:

curl -sS "$MESHI_BASE/review-queue?limit=50" \
  -H "Authorization: Bearer $MESHI_KEY"

curl -sS "$MESHI_BASE/events/summit-2026/review-queue?limit=50" \
  -H "Authorization: Bearer $MESHI_KEY"

Resolve an open review with one of three decisions:

Decision	Meaning
accept	The candidate is the right person.
reject	The candidate is not the right person.
distinct	The held source row represents a separate person.

curl -sS -X POST "$MESHI_BASE/review-queue/<REVIEW_ID>/resolve" \
  -H "Authorization: Bearer $MESHI_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "decision": "distinct", "reason": "Confirmed as a separate attendee." }'

For duplicate people, merge the source partner ID into the target partner ID:

curl -sS -X POST "$MESHI_BASE/review-queue/<REVIEW_ID>/merge" \
  -H "Authorization: Bearer $MESHI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "source_kind": "attendee",
    "source_partner_id": "att-dupe",
    "target_kind": "attendee",
    "target_partner_id": "att-1001",
    "reason": "Same person in source system."
  }'

You can inspect a single attendee’s identity decision history:

curl -sS "$MESHI_BASE/events/summit-2026/attendees/att-1001/identity?limit=50" \
  -H "Authorization: Bearer $MESHI_KEY"

Decision history is ordered descending by created_at.