Punchout
Connection, credential and inbound-document administration for cXML punchout buyers. The inbound order endpoint, POST /punchout/v1/{tenant_id}/cxml, is served outside /api/v1 and not documented here, because a cXML client cannot parse this API's RFC 9457 error responses and instead authenticates with a shared secret carried in the document body. It has its own page on this site instead: https://docs.spendone.tech/docs/guides/integrations/punchout-cxml.
List punchout authentication refusals
Per-day counters of inbound cXML requests refused before authentication succeeded: an unknown or revoked shared secret, a secret presented at another tenant's path, a deactivated connection, a buyer identity that does not match, a document that would not parse, and the endpoint's own rate limit. These requests produce no punchout document, because no tenant is trusted at the point they are refused, so this is the only record of them. It carries no source address, no presented secret and no request body.
List punchout connections
Paginated list of a tenant's configured buyer punchout connections.
Create a punchout connection
Create a punchout connection.
Get a punchout connection
Reads a connection and its non-secret credential metadata. This is the only GET a credential is reachable from; the plaintext secret is never included, at mint or here.
Update a punchout connection
Full replace of the connection's editable fields. is_active is not one of them: deactivation is its own route.
Mint or enroll a punchout credential
Mints a shared secret bound to the connection and returns it, shown exactly once and never retrievable again. A request carrying a secret enrolls that caller-provided string instead - the SAP Business Network supplier-account secret, one per Ariba account, so every customer's connection enrolls the same one - and returns an empty secret field rather than echoing it back.
Revoke a punchout credential
Revoking is one-way: a revoked credential answers the same indistinguishable 401 as an unknown one on the cXML endpoint.
Deactivate a punchout connection
Sets is_active false. Reversible (no route exists yet to reactivate), so this answers 200 plus the updated entity rather than 204.
Configure outbound punchout delivery for a connection
Sets the delivery endpoint, shared secret, identities, deployment mode and the two per-document-type enable flags. The secret is write-only and is never returned by any route; omitting it leaves the stored one unchanged. Turning both enable flags off is how outbound delivery is switched off.
Send a test document to a punchout connection's endpoint
Emits one synthetic ConfirmationRequest to the connection's configured delivery endpoint in deployment mode test, waits for the buyer's answer and reports it verbatim, so an operator learns within seconds whether the endpoint and the shared secret work instead of on the next real order. The synthetic document is stored for audit with an order id that cannot collide with a real buyer order, and no job is enqueued: the test send is the delivery.
List punchout documents
Paginated list of received/sent cXML documents, the audit and replay surface for every connection. Each row omits raw_document; read one document to get its payload. Filterable by status, e.g. failed to find orders whose conversion to a purchase request gave up, by direction (the failed-delivery list an operator works from is direction=outbound), and by connection_code for one connection's share of the log.
Get a punchout document
Reads back one received or sent document by its SpendOne-side code, redacted (raw_document has had any shared secret stripped before storage, see cxml.RedactSharedSecret).
Redeliver an outbound punchout document
Puts an outbound document that no job will ever deliver back in the delivery queue: status delivery_failed, or queued behind a hold. The stored bytes and the payloadID are kept, so the buyer deduplicates the redelivery against the first attempt. A document already sent, or queued with a live job on its way, is refused with 409.
Reprocess a failed punchout document
Puts a failed inbound order document back in the queue and re-runs the order-to-purchase-request conversion against it. Only a document in status failed can be reprocessed. A document held because it revises an order that already converted needs its live purchase request canceled and deleted first; until then the reprocessed conversion fails the same way again.