ADMIN
Returns the fulfillment orders belonging to the given external user, newest
first (by last_mutation_date). Each item includes its issued tickets inline,
so a single paginated call is enough to render "all tickets for this user".
external_user_id is the same identifier the integrator supplied to
POST /session when generating the user's authorization code — there is no
separate platform user ID.
Orders without tickets yet (PENDING / CONFIRMED before barcodes are
assigned) are returned with an empty tickets array.
Deliverable PDF URLs are not included in list responses — call the
single-order endpoint for a presigned download URL.
Unknown external_user_id yields an empty list (no 404). This avoids
leaking user-existence signals to integrators.
| 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
The same payload as GET /me/fulfillment/orders, addressed by
customer instead of by session — so your backend can read a customer's orders and tickets
without holding their credentials.
That covers the cases a storefront cannot: a support desk answering "where are my tickets", a CRM
or account view rendered server-side, a reconciliation job, and guest purchases, which never
appear under /me/* because there is no session to resolve.
Authorisation and scoping
| Credential | S2S token (client_credentials) |
| Scope | funtrips/fulfillment.read |
| Campaign | Resolved from the token's campaign claim |
external_user_id is your identifier for the customer — the same value you passed to
POST /session. It is stored verbatim and there is no separate platform
user id, so no mapping to maintain.
Request
curl "https://api.acc.funtrips.io/v2/admin/fulfillment/users/customer-4815162342/orders?limit=20&status=COMPLETED" \
-H "Authorization: Bearer $S2S_TOKEN"| Parameter | Type | Notes |
|---|---|---|
external_user_id | path | Your identifier for the customer |
limit | integer | 1–100, default 20 |
next_token | string | Cursor from meta.pagination.next_token |
status | enum | Filter to one lifecycle state |
The response is data.items — a paginated array of orders with their tickets inline, newest first
by last_mutation_date. Identical in shape to the customer-facing list,
including the empty tickets array on orders still being fulfilled.
An unknown customer returns an empty list
Not a 404. A customer who has never ordered and a customer who does not exist are indistinguishable
in the response, deliberately — otherwise this endpoint would answer "does this person exist?" for
any identifier you cared to try.
So an empty list means "nothing to show", never "wrong id". Verify the external_user_id against
your own records rather than expecting the API to tell you.
No PDF URLs here
deliverable is omitted from list responses. For the ticket document, call
the single-order endpoint.
Errors
| Status | Meaning | What to do |
|---|---|---|
400 | Invalid status value or malformed limit | Fix the request |
401 | S2S token missing, expired or invalid | Re-fetch the token, retry once |
403 | Token lacks funtrips/fulfillment.read | Provisioning — contact us |
500 | Server-side fault | Retryable |
Fulfillment routes answer with status and title — branch on the status code. See
Error handling.
Notes
customer_emailis personal data. Do not log it; logorder_idand the correlation id.- Filter
REORDEREDout of anything resembling a ticket list — those barcodes are voided.