Record verified non-financial Commerce reconciliation
Requires both commerce:sales:read and commerce:sales:reconciliation:write; existing credentials/OAuth grants receive no new scopes. Discover list_tickets with includeCommerce=true, inspect get_ticket purchase evidence, select a human owner, start work, then use the fresh Commerce sourceVersion and a new Idempotency-Key for this intent. The Commerce token is separate from ticket revision. Requires outcome, supporting reference and a note verifying the current issue. Stores a separate reconciliation record without rewriting historical financial records. External reconciliation is not provider-confirmed booking success. Agent/credential identity is audited directly. Built-in Agent approvals remain required. Refunds, payouts and booking retries remain human actions. Commerce completion synchronizes the exact ticket cycle; generic Resolve/Cancel cannot bypass policy. On a stale token (409), read current evidence before deciding a new command. On an uncertain response, read the purchase/ticket first and retry the identical body with the same key only to reconcile the same intent; never blindly create a new intent. Current tenant and test/live mode are fixed by authorization.
Authorizations
Server-side tenant-scoped credential created from Build > API Keys.
Headers
1 - 200Path Parameters
Body
Response
Durable Commerce command result. Read back the exact ticket and purchase after acceptance or uncertainty.
test, live x >= 0x >= 0fulfill, reconcile refund, retry_reservation, payout True only for successful provider booking state plus required stored provider identifiers; reconciliation alone never sets this.