What to Look for in a Container Visibility API

Quick answer

Carrier visibility APIs are not equal. Evaluate four things first: freshness, coverage, correctness, and consistency. Then check the reliability layer: signed webhooks and retries, rate limits, pagination, idempotency, and monitoring. Carrier maturity varies by line and product, so verify on the lanes you actually move.

How a good visibility API actually works

A visibility API exposes shipment, transport, and equipment events in a standard model. You pull the current state, then subscribe so updates arrive automatically when carriers revise ETAs or publish new milestones. A robust implementation delivers events in order, distinguishes planned, estimated, and actual timestamps, and links transshipment legs so mother and feeder vessels are handled cleanly.

Plain-language flow
1) Provide a BL, booking, or container ID.
2) Get current milestones and ETA.
3) Create a subscription for changes you want.
4) Receive pushed events to your webhook as changes occur.
5) Validate the signature, deduplicate, store, and notify your team.

The four dimensions that separate good from average

1) Freshness

How quickly do ETA or milestone changes appear after the carrier updates its systems? Ask for typical latency windows by leg type, and test whether mid voyage changes like rollovers or port omissions trigger events.

2) Coverage

Do events arrive reliably across your carriers and trade lanes? Confirm feeder and mother vessel legs are linked, transshipment milestones appear, and inland rail or truck events are available where you need them.

3) Correctness

Are events true and complete, and do they arrive in order? Look for low false positives, clean de-duplication, and full chains from origin gate in to empty return with valid location codes.

4) Consistency

Can your team read events without translation effort? You want stable field names, correct use of planned versus estimated versus actual timestamps, and consistent acceptance of container, booking, and BL identifiers.

Reliability engineering checklist for 2026 buyers

Webhooks

Signature verification on every callback.
Idempotency so retries do not create duplicates.
Return a fast 2xx and process asynchronously.

Retry model

Backoff and replay when your endpoint is slow or down.
Dead-letter handling so you never lose events.
Self-serve re-send for missed deliveries.

Pagination

Clear next page mechanics on large event lists.
Stable ordering so no events are skipped or repeated.

Rate limits

Published limits for reads, writes, and subscriptions.
Guidance for backoff and Retry-After handling.
Status page or changelog for incident visibility.

Monitoring

Delivery success rate and lag.
Alerts on dropped webhooks, 4xx spikes, and queue growth.
Audit trail mapping every notification to your receipt.

Do all carriers provide webhooks and DCSA-mapped events?

Not uniformly. Carriers are on different timelines and product stacks. Treat DCSA alignment and webhook availability as per-carrier questions, then verify during trials.

Carrier baseline reality check (examples to test)

Maersk. Offers webhook products for shipment notifications and booking status. Track and Trace Plus is available to approved developers. Confirm payload fields and any DCSA mapping during onboarding.
MSC. Provides a Track and Trace subscription that delivers events through a managed delivery channel. Documentation references DCSA-aligned event formats.
Hapag-Lloyd. The portal supports email tracing subscriptions. API offerings exist for data solutions, but track and trace webhook subscriptions are not publicly documented in the same way as email alerts.
CMA CGM. API portal presents a DCSA Track and Trace specification with event subscriptions and mentions webhook delivery. Access and specifics depend on registration and approval.

Use these as starting points, not assumptions. Validate what you will actually receive on your lanes.

Where evaluation often goes wrong

Only testing the happy path. Run your own BLs and containers for the last 30 days and include at least one transshipment.

Evaluating a single lane. Mix Asia–Europe and Trans-Pacific. Include a vessel change.

Ignoring failure modes. Simulate endpoint downtime and throttling. Confirm retries, signatures, and idempotency behavior.

Assuming “DCSA compliant” equals “ready for ops.” Standards reduce ambiguity, but implementation varies. Prove it under load.

Practical next steps

1) List your lanes and carriers. Include a transshipment and an inland leg.
2) Define acceptance benchmarks. Example targets: “ETA revision received within a defined window after the carrier update” and “All discharge events present.”
3) Run a 2 week trial. Subscribe to events for 10 live shipments across at least three carriers.
4) Exercise failure paths. Throttle your webhook, return 429, 500, and timeouts. Observe retries and signing.
5) Measure freshness and loss. Track latency from carrier update to your receipt, and count missed or duplicate events.
6) Decide with evidence. Choose the provider that proves coverage and reliability on your lanes.

What could still be confusing

Subscriptions cannot outrun source systems. Cadence varies by port, terminal, and carrier application stack. Expect variation and keep monitoring on. Revisit settings when your lane mix changes.

Why use TRADLINX instead of stitching carrier APIs yourself

Working directly with multiple carrier systems means different payloads, portals, and update cadences. TRADLINX provides one standardized, multi-carrier interface with event-based visibility across key milestones, so your team can work from a single source instead of juggling separate feeds. Our platform exposes robust APIs and webhooks, supports frequent data refresh with high request capacity, and detects exceptions such as rollovers or missed transshipments — helping you operate from one place with fewer manual checks.

Methods and sources

We used current standards documentation for Track and Trace and Commercial Schedules, and reviewed carrier developer portals for publicly documented capabilities. We also referenced widely accepted HTTP and webhook practices for rate limits, pagination, signature verification, and retries. Always confirm availability and payload details with each carrier during onboarding.