Update supported purchase fulfillment
Requires both commerce:sales:read and commerce:sales:fulfillment: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. Only routine, paid, non-historical purchases without a refund/active financial operation support fulfillment. This does not book with providers or send a customer message. 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.
Autorizaciones
Server-side tenant-scoped credential created from Build > API Keys.
Encabezados
1 - 200Parámetros de ruta
Cuerpo
Respuesta
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.