Skip to main content
DropHub publishes two deployments. They share one contract and share nothing else — data, credentials, and webhook secrets are separate.
The v2 External API is currently served on the sandbox host. Build and certify your integration there; confirm production availability with DropHub before cutting traffic over.
A production credential is never valid against the sandbox, and a sandbox credential is never valid against production. Keep them in separate secret stores so one cannot be reached from the other’s configuration.

​
Prerequisites

Before your first call you need:
  • A verified merchant account. Registration is an onboarding flow, not an API call you can automate away — see the sandbox quickstart.
  • An API credential. A client_id and client_secret issued to your merchant company.
  • A branch code and a pickup location code. Shipments are created against these, and both are readable from the API once your account exists.

​
Requests

Set these on every call.
Accept-Language is optional and selects a localized representation where one exists. Machine error codes never change with language; only human-readable text does.

​
The sandbox is steerable

The sandbox exposes fixture controls that production does not: bootstrap, readiness, reset, and a dispatch hold that parks the next shipment before it is offered to a driver. They exist so an integration test can reach a specific state deliberately rather than by waiting.
Sandbox fixture endpoints accept either an OAuth client-credentials token or a signed-in browser session. They are the only endpoints in this reference that accept a session cookie.