Create a new Payer record for the authenticated account. Idempotent via Idempotency-Key. Fires Payer.Created on success.
If externalId is supplied and already used by another resource of this type for the owning Account, the request returns 409 ResourceConflict; create is not an upsert. Use filter[externalId][eq] on the list endpoint to retrieve the existing resource.
profile.email is also not an upsert key, and a duplicate does not always conflict. Which of the two outcomes below you get turns on internal record keying, NOT on anything this API exposes — so handle both rather than trying to predict which:
-
409 ResourceConflictwithdetailCodepayments.PayerEmailConflict. Retrieve the
blocking payer withfilter[email][eq]on the list endpoint, thenPATCHit with
whatever you meant to change. An email held only by aDeactivatedpayer does not
conflict at all; that create proceeds. -
201with the PRE-EXISTING payer, reactivated if it wasDeactivated, and no
Payer.Createdwebhook fires. Nothing you submitted is applied, andevents.createdAt
is the original creation time — so a201does not by itself mean a payer was created.
| Time | Status | User Agent | |
|---|---|---|---|
Retrieving recent requests… | |||