Returns the completed fulfillment order (including tickets and deliverable)
for the given order ID.
The order must belong to the authenticated user and to the campaign resolved
from the JWT. If the order does not exist or belongs to a different user,
404 Not Found is returned without distinguishing between the two — this
prevents enumeration of order IDs across users.
If the order exists but tickets have not yet been assigned (status PENDING
or CONFIRMED), 409 Conflict is returned with a Retry-After header
indicating how long the client should wait before retrying.
| Time | Status | User Agent | |
|---|---|---|---|
Retrieving recent requests… | |||
Part of ticketing — Tickets and fulfillment explains the order lifecycle and how tickets are issued.
Why this endpoint exists
Right after a purchase you hold the order_id from Confirm — and nothing else. You do not have a fulfillment_order_id, because that only appears in the list response, which requires a session and does not exist for guests.
This endpoint closes that gap: it resolves the checkout order_id to the completed fulfillment order, with tickets and deliverable. It is the natural "order confirmation page" call.
Which id goes here
| Route | Id | Source |
|---|---|---|
GET /me/fulfillment/orders/{order_id} | order_id | Confirm checkout / Express |
GET .../{fulfillment_order_id}/tickets | fulfillment_order_id | List orders |
The two routes look alike and take different ids. This one takes the id from checkout — the qup-core order id.
Request
curl "https://api.acc.funtrips.io/v2/me/fulfillment/orders/$ORDER_ID" \
-H "Authorization: Bearer $END_USER_TOKEN"The response is the same FulfillmentOrderWithTickets object as get order tickets, including deliverable when a PDF exists.
Auth is "optional" but ownership still applies
The route is declared with the optional authorizer, so a request without a token is not rejected outright. Ownership is still enforced: the order must belong to the authenticated user and their campaign, and anything else returns 404.
The practical consequence is that this endpoint is a reliable order-confirmation call for signed-in customers. For guests, do not assume it resolves — deliver their tickets by e-mail and treat the confirmation page as best-effort. If a guest order page is a hard requirement, raise it with us rather than building on an assumption here.
The 409 polling contract
409 polling contractIdentical to get order tickets: while the order exists but tickets are not assigned (PENDING / CONFIRMED), you get 409 plus a Retry-After header.
This is the normal path on an order confirmation page — the customer arrives back from payment seconds after capture, and fulfillment takes a little longer than that. Expect several 409s before the first 200.
Honour Retry-After, back off exponentially, cap around 5 minutes, then fall back to "your tickets
are on their way by e-mail". The delay comes from the header; if you need the order's lifecycle
state as well, read it from the list endpoint.
Errors
| Status | Meaning | What to do |
|---|---|---|
401 | A token was sent and rejected | Re-authenticate |
404 | No fulfillment order for that order_id, or it is not yours | Check the id; see below |
409 | Tickets not ready yet | Honour Retry-After |
500 | Unexpected fault | Retryable |
No type field on fulfillment errors — branch on status.
A 404 immediately after checkout can also mean fulfillment has not been registered yet. Retry a couple of times with backoff before concluding the order is missing — and if it persists, the correlation id from the Confirm call is what we need to trace it.
Notes
- A date change replaces the tickets under the same
order_id. After a reorder, this endpoint returns the new order for that id; the original is markedREORDEREDin the list. So an order page built on this route shows the current tickets without any work on your side.