ADMIN
Re-sends the ticket email (with the consolidated PDF) for a completed
fulfillment order to the customer. Intended for server-to-server use by
qup-core — e.g. support requests, a lost email, or a corrected address.
The caller is a cross-campaign admin authorized by the
funtrips/fulfillment.write scope, so the endpoint is not
campaign-scoped: the order is resolved by fulfillment_order_id alone,
and an unknown id returns 404.
By default the ticket is sent to the email stored on the order. Supply
email in the body to override the recipient. A request body is required;
send {} to use the stored recipient.
Only COMPLETED orders that have a generated ticket can be resent —
otherwise 409 Conflict. If no recipient can be resolved, 422.
| Time | Status | User Agent | |
|---|---|---|---|
Retrieving recent requests… | |||
Idempotency-Key required — see below. Not campaign-scoped: the order is resolved by
fulfillment_order_idalone.
Part of ticketing — Tickets and fulfillment explains the order lifecycle and how tickets are issued.
Why this endpoint exists
"I never got my tickets" is the single most common post-purchase support request, and it usually
has a dull cause: the e-mail went to spam, the customer mistyped their address at checkout, or they
deleted it and want it again.
This re-sends the ticket e-mail, with the consolidated PDF attached, for a completed order — to the
address stored on the order or to one you override. One call, no file handling, nothing for your
support agent to copy around.
Use the tickets endpoint instead when you need the
document itself rather than an e-mail.
Authorisation and scoping
| Credential | S2S token (client_credentials) |
| Scope | funtrips/fulfillment.write |
| Campaign | Not scoped — the order is resolved by fulfillment_order_id alone |
Note the difference from the read endpoints: those resolve the campaign from your token, this one
does not. Pass an id you hold from your own records; an unknown id is a 404.
funtrips/fulfillment.write is provisioned separately from funtrips/fulfillment.read. Holding
the read scope does not grant this.
Request
A body is required. Send {} to use the address stored on the order.
# to the stored recipient
curl -X POST "https://api.acc.funtrips.io/v2/admin/fulfillment/orders/$FULFILLMENT_ORDER_ID/resend-ticket" \
-H "Authorization: Bearer $S2S_TOKEN" \
-H "Idempotency-Key: $(uuidgen)" \
-H "Content-Type: application/json" \
-d '{}'
# to a corrected address
curl -X POST "https://api.acc.funtrips.io/v2/admin/fulfillment/orders/$FULFILLMENT_ORDER_ID/resend-ticket" \
-H "Authorization: Bearer $S2S_TOKEN" \
-H "Idempotency-Key: $(uuidgen)" \
-H "Content-Type: application/json" \
-d '{ "email": "[email protected]" }'| Field | Required | Notes |
|---|---|---|
email | No | Override recipient. Omit or send null to use the stored address. If present it must be a valid address — an empty string is rejected |
An override changes where this e-mail goes. It does not correct the address stored on theorder, so a later resend without
you the wrong address at checkout, expect to pass the override every time.
Response
200 OK:
{ "data": { "status": "sent" }, "meta": { "correlation_id": "…" } }status: sent means the e-mail was dispatched — handed to the mail system, not confirmed as read.
Delivery to the inbox is not something this call can promise.
Idempotency
Idempotency-Key is required; omitting it is a 400. Keys are remembered for 24 hours.
It matters here because a support agent clicking twice should not send two e-mails. Generate one
key per intent — this agent resending this order to this address — and reuse it on retry.
| Outcome | Meaning |
|---|---|
200 | Sent |
208 | Already sent under this key. Treat as success; nothing was sent twice |
409 | Same key with a different body, or the order is not resendable — the two share a status, so read the response |
A deliberate second send — the customer asks again an hour later — is a new intent and needs a
new key. Reusing the old one returns 208 and sends nothing, which looks like success and
leaves your agent puzzled.
What cannot be resent
| Status | Cause | Recoverable? |
|---|---|---|
409 | The order is not COMPLETED, or no ticket document has been generated | Yes — wait for fulfillment, then retry |
422 | Every line on the order is shipped by the merchant, so there is no ticket to send | No. Terminal — retrying never succeeds |
422 | No recipient could be resolved, or the recipient is undeliverable (suppressed or invalid) | Only by supplying a valid email |
The distinction matters for a support tool: a 409 is "not yet, try again shortly", while a 422
means stop and tell the customer something else — either their order has no ticket by nature, or
the address will not accept mail.
Errors
| Status | Meaning | What to do |
|---|---|---|
400 | Malformed body, invalid email, or missing Idempotency-Key | Fix the request |
401 | S2S token missing, expired or invalid | Re-fetch the token, retry once |
403 | Token lacks funtrips/fulfillment.write | Provisioning — contact us |
404 | No order with that fulfillment_order_id | Check the id |
409 | Not resendable, or idempotency conflict | See above |
422 | No ticket to send, or recipient undeliverable | See above |
502 | The mail system could not be reached | Retry with the same key |
500 | Server-side fault | Retry with the same key |
Notes
- Do not log the recipient address. Log
fulfillment_order_idand the correlation id. - Confirm the address with the customer before overriding. This endpoint sends a document that
admits someone to a venue; an override typo delivers their tickets to a stranger.