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.

What’s available

Setting value	Courier
pathao	Pathao
steadfast	Steadfast
redx	RedX

The settings

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_provider → COURIER_DEFAULT_PROVIDER (.env) → the first courier that has credentials.

Wiring a courier

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).

Credentials are handled securely — and never echoed

Courier API keys live only in the encrypted Integrations store, never in the tenant config or .env, and are never returned by the public config endpoint. The config only names which courier is active.

Swapping a courier

Moving Pathao → Steadfast (or adding RedX) is: add the new courier’s credentials, change the selection. No redeploy of application code, no image rebuild — the shared package already knows how to talk to each.

Delivery pricing is separate

Which courier carries a parcel is one thing; what you charge the customer for delivery is another. See Delivery zones & fees.

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