Shipwell · Rate Limits

Shipwell Rate Limits

Shipwell does not publish fixed numeric rate limits in its public developer documentation. Access is company-scoped by API key, and usage is governed by the platform contract rather than a documented per-minute request cap. Clients should treat the API as rate-limited in principle - handle HTTP 429 responses with exponential backoff and honor any Retry-After header - and confirm exact limits with Shipwell for a given account. A fully separate sandbox environment exists for development and testing, where external integrations return mocked responses.

Shipwell Rate Limits is the machine-readable rate-limit profile for Shipwell on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 3 rate-limit definitions, measuring requests and deliveries.

The profile also includes 2 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Transportation Management, TMS, Freight, Logistics, and Rate Limiting.

3 Limits Throttle: 429
Transportation ManagementTMSFreightLogisticsRate LimitingQuotas

Limits

Core API Requests account
requests
not published
No fixed numeric request-rate limit is documented for the v2 Core API. API keys are company-scoped.
Events and Webhooks account
deliveries
not published
Webhook deliveries are server-to-endpoint HTTP POST calls; no documented delivery-rate cap.
Sandbox Usage account
requests
not published
Sandbox is separate from production and mocks third-party integrations; limits not documented.

Policies

Backoff Strategy
Clients should implement exponential backoff with jitter and honor Retry-After on any 429 response.
Idempotency and Environments
Production and sandbox are fully separate; objects created in one environment cannot be manipulated from the other.

Sources