How are parcel tracking APIs usually priced?
There is no universal price per parcel-status query. A supplier may charge for requests, successful lookups, registration or subscription of a tracking number, immediate refresh credit, or a package period. Confirm the billable event first, then budget from valid new tracking numbers under the current supplier plan, currency, volume, and quotation date.
Polling is not inherently cheaper than subscription, nor is webhook delivery inherently more expensive. The cost depends on how repeated requests for the same carrier and tracking number are counted and how long tracking remains active.
| Integration | Trigger | Engineering concern | Cost question | Suitable use |
|---|---|---|---|---|
| User-initiated lookup | Request when the order is opened | Cache and rate limit | Does every repeated request charge? | Infrequent viewing and explicit refresh |
| Registration/subscription plus webhook | Register after shipment; receive updates | Signature, idempotency, recovery lookup | Cost per registration and tracking period | Automatic order state and exception notice |
| Scheduled polling | Backend queries by state and age | Controlled cadence but possible waste | Charge per request or per parcel? | No webhook or recovery mechanism |
| Carrier or commerce-platform API | Connected to the carrier contract or platform order | Direct data but limited network | Eligibility, contract fee, quota, multi-carrier gap | Concentrated carrier or platform orders |
| Multi-carrier aggregator | One schema across domestic and international carriers | Mapping quality and carrier differences | Standard/special carriers, fields, regions | Broad and cross-border fulfilment |
Kuaidi100's help material says usage is charged by shipment and that, when real-time lookup and subscription are used separately or together, the same carrier and tracking number is counted once within 40 days; current package prices belong in the enterprise console. Its real-time lookup documentation discourages bulk, high-frequency duplicate requests and points automatic updates toward push.
17TRACK's plan explanation uses tracking quota: successfully registering a number consumes credit, while continuing tracking does not repeatedly consume registration credit. Its API documentation describes different cache levels and consumption for real-time retrieval; changing the carrier or deleting and registering again may also consume credit. These different rules show why “cost per query” is the wrong universal comparison.
When defining budget, scope, and cost assumptions, also compare How are custom software projects usually priced? and Why should clients usually pay third-party suppliers directly?; the linked guidance adds context that should be considered in the same decision.
Budget from valid new shipments
Use annual API cost = standard billable tracking volume × standard rate + special carrier/immediate refresh credit + excess or optional capability + integration and operating cost.
Tracking volume may differ from orders: one order can split into parcels, a return creates another number, and carrier correction or re-registration may count again. Whether test or no-result numbers charge depends on the supplier. From a historical period covering busy and quiet seasons, collect new numbers, split rate, domestic/international mix, carrier distribution, transit duration, lookup and refresh count, and exception rate. Also check package expiry and tiers so excess inventory does not lapse.
Accept trustworthy tracking, not merely JSON
Test real domestic and international carriers for identification accuracy, first-event delay, event completeness, delivered-state agreement, exception coverage, and push delay. Webhooks require signature verification, idempotency, raw-event retention, exponential retry handling, and scheduled recovery for missed events. The frontend should not call the supplier on every refresh.
Store the original carrier event, normalized tracking state, and business order state separately. Operations must be able to correct a bad mapping without rewriting source evidence. Stop unnecessary polling after a terminal state according to the actual contract and retain records only for the support, audit, and privacy period. Do not invent a cancellation lifecycle shared by all suppliers.
Wavesteam tests at least two candidate services against authorized historical samples, compares coverage and event quality, and then calculates annual sensitivity from each actual billable event. The client owns the supplier account and bill; we deliver normalized fields, reliable callbacks, monitoring, and a replaceable adapter without hidden markup on tracking quota.