Skip to content

Courier providers

The courier integration is a shared, versioned package. Each adapter maps its vendor’s API onto one canonical shape (create_consignment / fetch_label / parse_webhook, and vendor statuses → a canonical courier status), so switching courier is a config change, never an edit.

Setting value Courier
pathao Pathao
steadfast Steadfast
redx RedX
Setting Purpose Default Where
courier_provider The courier to use for this store blank → the deployment default, then the first with credentials Tenant config → Providers
COURIER_DEFAULT_PROVIDER Deployment-wide default courier "" (unset) .env
courier credentials API keys for the courier Integrations (encrypted)

The active courier resolves in order: TenantConfig.courier_providerCOURIER_DEFAULT_PROVIDER (.env) → the first courier that has credentials.

  1. Add the courier’s credentials as an App integration — encrypted at rest automatically.
  2. Set courier_provider in the tenant config (or COURIER_DEFAULT_PROVIDER in .env for a deployment-wide default).

The Test connection button on a courier card reports “Config OK — not live-tested”: it confirms your credentials load and the adapter initialises, which is what catches the real-world failure (a key that was never pasted in, or half of one).

It deliberately does not call the courier — the only meaningful “test” a courier API offers is booking a consignment, and Nudova is not going to book a real parcel to tick a box. You’ll know the credentials are right the first time you book for real.

Related: Payment providers · SMS provider · Phone-risk provider · COD & fraud review.