Reliability & Status

Carrier APIs rate-limit, slow down and sometimes go dark. That's outside anyone's control, but it shouldn't be your problem. Direct Carrier Connections is built so that carrier trouble never turns into lost data or retry logic in your code.

Carrier throttling

Many carriers limit how often they can be called. R+L, for example, allows 350 requests every 15 minutes, and CloudTrucks allows 75 a minute. Go over and the carrier starts refusing calls.

Shipwell schedules every tracking and document request to each carrier within that carrier's own limit, per carrier account. When your volume spikes, requests are spread out instead of sent in a burst. So:

• a busy day never trips a carrier's rate limit,
• no tracking update or document is dropped because a carrier said "too many requests",
• one carrier's limit never slows down your requests to any other carrier.

You don't build any of this yourself: no backoff, no queue and no per-carrier limits in your code.

Jobs that always finish

A carrier that never answers can't leave you waiting forever:

• Rating closes any carrier attempt still waiting after about 30 minutes, so every rating job reaches a terminal status.
• Dispatch marks a booking the carrier never confirms as EXPIRED .
• Tracking has an expiry. A shipment that never reaches a final state is retired as EXPIRED , instead of being polled forever.

Rating jobs, dispatch jobs, tracking timelines and document collections all carry is_terminal, so every polling loop has a clear end.

Tracking webhooks are bounded too. A delivery your endpoint doesn't accept is retried for about 47 hours, only when retrying can help: timeouts, network errors, 408, 429 and 5xx. See Tracking Webhooks.

Safe retries

Networks fail. Send an Idempotency-Key header on POST /rating/jobs and POST /dispatching/jobs, and a retry with the same key and body returns the original job. A timed-out booking you retry never tenders a second pickup, and a retried rating never quotes every carrier twice.

Carrier health and status

Shipwell measures every call it makes to a carrier, per carrier and per operation, for error rate and latency, and knows which integration version each carrier is running.

Platform and carrier status is published at status.shipwell.com. If rating, dispatch, tracking or documents for a carrier are failing or slower than usual, check there first. A carrier-side outage or slowdown shows up there, and you can subscribe for updates as incidents happen.

Observability

Every request Shipwell sends to a carrier, and every response it gets back, is logged and monitored. Shipwell's integrations team watches error rates and response times across all carriers on live dashboards, with error reporting across every environment. When a carrier changes its API or starts failing, we see it and fix the integration on our side. Your code doesn't change.

Carrier changes are our job

Carriers change their APIs, retire endpoints and rename status codes. Each carrier integration is versioned and updated by Shipwell. Because tracking states are worked out when you read them, an improvement to how a carrier's codes are understood even applies to movements already recorded.