Idempotency keys

The API uses your identifiers as idempotency keys. There is no separate Idempotency-Key header. Safe retries depend on sending the same identifier.

Endpoint	Idempotency key	Replay behaviour
POST /onboardings	partner_user_id	Returns the original onboarding_id, already_existed: true, HTTP 200. The email is not re-sent.
POST /claims	partner_claim_id (per entity)	Returns the existing claim_id, already_existed: true, HTTP 200. Documents are not re-linked.
POST /connect-requests	none	Each call mints a fresh, single-use token.

Guidance

• Always send partner_user_id on onboarding, and reuse it on retries.
• Always send partner_claim_id on claims (it is required) and reuse the same value on retries. It is what makes a retried POST /claims replay the existing claim instead of creating a second one. The key is scoped per entity: the same partner_claim_id sent with a different entity_id creates a separate claim.
• On an onboarding replay, the original magic link cannot be recovered, so magic_link_url comes back null. If you need a fresh link, onboard under a new partner_user_id.
• On a claims replay, document_ids is always empty. Documents are linked only on first creation.