Tickets Overview

Working with Support Tickets

The Tickets API lets your application open, track, and resolve support cases tied to a company's account and shipments — lost packages, damage claims, overweight disputes, carrier issues, credit line requests, and more. It is part of the Queries API and is the same engine that powers the ticket center in the Envia dashboard.

A ticket is a conversation with a lifecycle. Each ticket has:

  • A type (ticket_type_id) — what the case is about.
  • A status (ticket_status_id) — where it is in the workflow.
  • A message thread (comments) exchanged between the customer and the support agent.
  • Variables — structured, type-specific form data (sent as a JSON string in data).
  • File evidence — photos or documents attached to the case.
  • Optional references — a shipment, a credit reference, or a warehouse package.

Environments & authentication

All ticket endpoints live under the Queries API host and require a Bearer token in the Authorization header. Every request is automatically scoped to the company that owns the token — you only ever see and act on your own company's tickets.

EnvironmentBase URL
Sandboxhttps://queries-test.envia.com/
Productionhttps://queries.envia.com/
HeaderRequiredDescription
AuthorizationyesBearer YOUR_API_TOKEN
Content-Typefor POST/PUTapplication/json (except file upload, which is multipart/form-data)
Accept-LanguageoptionalLocale for translated fields (en, es, …). Defaults to the account locale.
🔑

Tokens are issued per company. See API Token for how to obtain and rotate yours.

Endpoint overview

Ticket types

Every ticket has a ticket_type_id. Fetch the live catalog (with localized name and the UI rules for each type) from GET /tickets/types.

IDTypeTypical use
1InternationalInternational shipment service request
2CarrierCarrier activation / carrier issue
3OverweightDispute an overweight surcharge
4LostPackage lost in transit
5DamagedPackage delivered damaged
6Wrong addressDelivery to the wrong address
7RefundRefund request
8DelayShipment delayed
9Payment pendingReport a pending payment / receipt
10PO box package pendingWarehouse package pending
11PO box package delayedWarehouse package delayed
13TheftStolen package
14RedirectionRedirect a shipment
15LTL / FTLFreight shipment request
16Credit LTL / FTLFreight on credit
17PartnersPartner request
18Service request infoRequest to enable a service
19Credit lineCredit line application (requires documents)
20Delay paymentRequest a payment deadline extension
21Irregular packageIrregular package report
23Service guaranteeService guarantee claim
24Partial refundPartial refund request
25Delivery attemptFailed delivery attempt
26Customs delayShipment held in customs
👍

The table above is a reference snapshot. Always read GET /tickets/types at runtime — types, availability, and their input rules are managed server-side and can change.

Ticket statuses

Each ticket carries a ticket_status_id. Statuses are grouped into the two tabs you see in the dashboard via the status_group query parameter.

IDStatusGroup (status_group)Meaning
1PendingactiveNew, awaiting agent review
4IncompleteactiveMissing required data / files
5Follow upactiveNeeds agent action after a client reply
6In reviewactiveBeing reviewed by an agent
2Accepted (Solved)resolvedResolved in the customer's favor
3Declined (Closed)resolvedClosed / rejected

Lifecycle rules

  1. Manually created tickets start as Pending (1).
  2. Automatically generated tickets (from a shipment incidence) start as Incomplete (4) until the required data/files are provided.
  3. When a customer replies to a ticket that is In review (6), it moves to Follow up (5) so an agent re-engages.
  4. Accepted (2) and Declined (3) are terminal — no more comments or status changes are accepted.
  5. A ticket auto-closes to Accepted (2) when the related shipment is delivered (for delay/redirection cases).

Errors

StatusWhen it happens
400 / 422Invalid payload or query parameters (failed validation), or an already-rated ticket.
401Missing or invalid Bearer token.
409Duplicate open ticket for the same shipment + type.

Validation errors return a Boom-style body:

{
  "statusCode": 422,
  "error": "Unprocessable Entity",
  "message": "Invalid data."
}

Typical ticket flow

  1. Create a ticket with POST /company/tickets, choosing the right type_id and referencing a shipment or credit when applicable.
  2. Attach evidence with PUT /company/attach/evidences/{ticket_id} if the case needs proof.
  3. Poll GET /company/tickets/{ticket_id} (or list with status_group) to watch the status advance.
  4. Reply through POST /company/tickets/{ticket_id}/comments whenever the support agent asks for more information.
  5. Resolve — the ticket reaches Accepted or Declined; optionally rate it with POST /tickets/ratings/{ticket_id}.
🛟

Need Help?

Building against the Tickets API and something isn't behaving as expected?
Our support team is ready to help 🚀

Create a support ticket here and we'll guide you through setup and troubleshooting.