Moves one id's purchases, credits, analytics and experiment rows onto another id, from your server. Call it when a guest signs up and you know the guest id and the account id are the same person.

Authenticated with your secret key (zs_sk_*), sent in X-ZeroSettle-Key or as Authorization: Bearer. Never call it from an app. A publishable key is refused with 401 secret_key_required.

The merge is one way, and an id that has been merged away cannot be merged again. If both customers hold a live entitlement to the same non-consumable product (a subscription, including a trial or one cancelled but still running out its period, or a one-time unlock; consumables never conflict), the call is refused and nothing moves. Stripe and the stores are never changed. If from has no customer record at all (no purchase, checkout or Stripe customer), only its analytics and experiment rows move: the call succeeds with zero counts, sends no event and sets up no forwarding. A guest with a customer record but no purchases takes a normal merge, with zero counts, forwarding and an identity.reconciled event. Purchased credits move and add to the account's balance; plan allowances do not move.

Idempotency. Send an Idempotency-Key. A replay with the same key and the same ids within 24 hours returns the stored result. After 24 hours the same ids still return the original success. A key reused with different ids is refused with 422 idempotency_mismatch, permanently: a key stays bound to the ids it first succeeded with. Refusals are not stored, so a retry after a refusal runs again.

A merge sends an identity.reconciled webhook, including a merge that moved nothing. An analytics-only move sends none.

Limits. 300 calls a minute and 50,000 a day per project, counted separately from link-token presentations. Over a limit the response is 429 with Retry-After.

{
  "reconciliation_id": 4821,
  "from": "3f1c9c52-8f5e-4a52-9d9c-0f0b6f1a7c11",
  "into": "user_8472",
  "moved": {
    "transactions": 2,
    "entitlements": 1
  }
}