The specification has two interfaces over one object model: Both interfaces return the same canonical objects with the same field names, IDs, enums and metadata namespaces. A Shipment from query { shipment(id:) } is the object GET /v1/shipments/{id} returns. CRUD operations available on both interfaces behave identically: same validation, same state rules, same events.

Conventions

  • Authentication and scopes are the same as REST (Conventions §3): Authorization: Bearer …, Shipping-Version, and Shipping-Account to act for a connected or member account. Each field requires the scope of its REST counterpart (shipments:write for createShipment, catalog:write for createService).
  • Idempotency. Mutations that create or act accept the Idempotency-Key header, with the same rules as Conventions §8. Fields that spend money are flagged on their page.
  • Errors use the standard GraphQL errors[], and extensions carries the REST error object: extensions.type, extensions.code (the Conventions §9 registry), extensions.param, extensions.request_id.
  • Lists return { data, has_more } with limit, startingAfter and endingBefore arguments, mirroring REST cursor pagination.
  • Events. Mutations emit the same webhook events as their REST counterparts. Subscribing over GraphQL (subscription { events(types: […]) }) is an optional capability (graphql.subscriptions).
  • Schema. The full SDL is published at graphql/schema.graphql, and implementers SHOULD serve introspection to authenticated clients.
Every field below has its own page with arguments, return fields and request, variables and response examples. Module chapters describe the behavior.

Accounts

Apps

Batches

Billing

Carriers

Catalog

Connections

Consolidation

Data Network

Document Uploads

Events

Files

Fleet

Inbound

Injection

Integrations

Inventory

IoT

Jobs

Manifests

Network

Pickup Schedules

Pickups

Pricing

Products

Rates

Routes

Shipments

Templates

Tracking

Trade

Webhooks