There are two different ownership boundaries in a tracking application. Trace enforces ownership for records within the authenticated Trace account. Your application must additionally decide which merchant user or buyer can see each order.
A valid API key proves access to a Trace account, not that the browser requesting a shipment owns the order. Keep the key on your server and resolve the browser’s authorization before making the upstream call.
Bind every local mapping to its owner
Store the merchant or tenant identity with the local order-to-shipment mapping. Retrieve records using both the requested object ID and the authenticated owner. Do not fetch an arbitrary shipment using a shared key and rely on hiding its URL in the interface.
If several merchants share one Trace account, Trace sees that account boundary rather than your internal tenant model. Your service must enforce the finer isolation. Separate Trace accounts can provide another boundary, but they do not replace buyer-level access checks.
Return only what the customer needs
Build an allowlisted customer view containing status, relevant event text and verification context. Keep internal references, operational errors and merchant metadata out unless they are necessary for the buyer. A carrier number can reveal a shipment history and should not be treated as a harmless public lookup token.
Signed links, if your application supports them, need explicit expiry, scope and revocation behavior. This is an application design decision, not an implicit capability granted by a Trace tracking number or shipment ID.
Route events through a verified mapping
Authenticate the raw webhook body, deduplicate the event and resolve the owned shipment to your local tenant mapping. Do not route a payload to a buyer purely because an untrusted order label matches a local string. Keep event handling and customer notification authorization in the same reviewed workflow.
| Boundary | Required check |
|---|---|
| Browser → your server | Valid session or deliberately scoped access token. |
| Order → buyer | Order belongs to the authenticated principal. |
| Shipment → tenant | Saved mapping belongs to the intended merchant. |
| Webhook → projection | Valid signature, event identity and mapped shipment. |
| Cache → response | No shared response leaks across accounts. |
Use two accounts and deliberately swap identifiers
Create isolated fixtures for two owners. Try another owner’s shipment ID, order reference, result cursor and webhook delivery ID wherever your application accepts them. Verify that denied requests reveal no private data. Repeat after logout and through any caching layer.
Authorization failures should remain failures even when the identifier is valid. A helpful error message must not become an object-enumeration endpoint that exposes another tenant’s shipment details.
Common questions
Does Trace implement my marketplace’s buyer accounts?
No. Trace account ownership is one layer. Your marketplace remains responsible for seller membership, buyer sessions and order-level authorization.
References & next steps
Implementation details were checked against Trace’s current API. External product details may change; verify the linked documentation before deciding.