Tracking API Pricing Models Explained: Per-Call vs Per-Shipment & How to Estimate Your Real Cost
Per-call tracking API pricing charges for billable requests; per-shipment pricing charges for a defined tracking unit, such as a registered tracking number. Neither is automatically cheaper. To estimate your real cost, compare both models against the same shipment volume, update requirements, tracking duration, and billing rules, then add platform fees, overages, and integration costs.
For engineering, operations, and procurement teams, the useful comparison is not simply price per call versus price per shipment. It is the total cost of delivering the shipment visibility your business needs. A low request rate can become expensive with frequent polling, while a low shipment rate can be misleading if its tracking window or included services do not fit your workflow.
What each pricing model actually measures
The first step is to separate three things: an API request, a shipment registration, and a tracking update. They are different events, and a contract can assign different billing treatment to each.
| Comparison point | Per-call pricing | Per-shipment pricing |
|---|---|---|
| Billing basis | Requests or request units defined as billable | Shipment units defined as billable |
| Main cost driver | How often the application makes chargeable requests | How many chargeable tracking units enter or remain in scope |
| Billing question to resolve | Which endpoints, responses, and batch items count? | What constitutes one shipment, and how long is tracking included? |
| Potential cost exposure | Repeated polling, retries, and unnecessary lookups | Duplicate registrations, multiple parcels, and tracking-window limits |
| Strongest conditional fit | Low-frequency lookups with controlled request volume | Ongoing monitoring when updates are included in the shipment fee |
Per-call does not necessarily mean every HTTP request costs the same
A quote needs to identify the billable endpoints and their units. Registering a tracking number, retrieving stored results, requesting a refresh, and managing subscriptions could have different treatment. Do not assume a failed request is free, or that a successful request is always chargeable.
Batching also needs an explicit definition. One request containing 100 tracking numbers might count as one request, 100 tracking units, or another contractual quantity. Reducing network traffic does not establish a billing saving unless the metering rules support it.
Per-shipment does not necessarily mean per order
An ecommerce order can produce several parcels. If the chargeable unit is a tracking number, a split order may consume multiple units. Returns, replacement shipments, and carrier handoffs also need clear treatment.
Ask whether the fee purchases tracking for a specified period, through a defined completion event, or under another limit. Also establish whether already registered shipments incur new charges in a later billing period. These details matter more than the label on the pricing plan.
Estimate cost from your workflow, not just your order count
Use a representative operating period and build a forecast from shipment-level data. Include both new shipments and any older shipments that still require monitoring. If your data is incomplete, make the assumptions visible rather than presenting the result as a precise quote.
- Count trackable parcels. Start with unique parcel tracking units, not checkout orders. Keep outbound parcels, returns, and replacements separate until their billing treatment is confirmed.
- Measure monitoring duration. Estimate how long each shipment needs updates, including pre-transit and exception periods where relevant.
- Define the required update frequency. Specify how frequently your application needs fresh information and whether that changes by shipment status.
- Map the API workflow. List registrations, result lookups, refresh requests, corrections, retries, and any other endpoints your integration will use.
- Apply the billing rules. Convert technical activity into billable calls or shipment units using the proposed contract.
- Add non-usage charges. Include the applicable subscription, minimum commitment, optional services, and implementation or operating costs.
For a simple polling integration with one tracking number per lookup, the starting estimate is:
Lookup requests = monitored shipments × average monitored days × lookups per day
This shortcut assumes that every shipment follows the same average schedule. A more accurate model sums the requests for each shipment or shipment cohort, then adds registration calls and other billable activity. If shipments remain active across month-end, allocate their requests to the billing periods in which those requests occur.
A worked example: when the cheaper model changes
The following numbers are invented solely to demonstrate the calculation. They are not 17TRACK prices, supplier quotes, or market benchmarks.
Assume 10,000 parcels are registered and fully monitored within the same modeled period. Each requires one registration request and three lookup requests per day for eight days. Assume every request is billable, each request concerns one parcel, and there are no retries, batch discounts, allowances, or fixed fees.
- Registration requests: 10,000.
- Lookup requests: 10,000 × 8 × 3 = 240,000.
- Total billable requests: 250,000.
- Illustrative per-call rate: $0.002.
- Illustrative per-shipment rate: $0.04, including the required monitoring.
The per-call usage cost is 250,000 × $0.002 = $500. The per-shipment usage cost is 10,000 × $0.04 = $400. Under these assumptions, per-shipment pricing costs $100 less for usage.
Now change only the lookup frequency to once per day. The request count becomes 10,000 registrations plus 80,000 lookups, or 90,000 calls. Per-call usage falls to $180, while the illustrative per-shipment usage remains $400. The preferred model changes because the workload changes, not because either pricing structure is inherently better.
Find the break-even point
When both plans have no fixed charges, allowances, or extra fees, use:
Break-even billable calls per shipment = shipment rate ÷ call rate
In the example, $0.04 ÷ $0.002 equals 20 billable calls per shipment. Above 20 calls, the shipment fee is lower; below 20, the call fee is lower. Registration calls count toward that threshold under the example's assumptions.
This shortcut is not sufficient for tiered plans, prepaid credits, different endpoint rates, or minimum commitments. For those offers, calculate the complete invoice at each forecast volume rather than comparing headline unit rates.
Webhooks can reduce polling, but billing still needs verification
Polling means your application repeatedly asks for tracking information. A webhook allows a service to send an event to your application, reducing the need for repeated lookups when the event stream meets your requirements.
However, fewer lookup requests do not automatically mean a lower invoice. Confirm whether webhook delivery is included, whether deliveries or retries are metered, and whether reconciliation lookups remain necessary. Your application also needs to handle duplicate or out-of-order events safely and recover from delivery failures.
There is another distinction worth protecting: requesting information more frequently does not guarantee that the underlying carrier has produced a new scan. Ask what a lookup returns and how data refresh works before paying for a polling frequency that may add little operational value.
Costs that a headline rate can hide
Included allowances, minimums, and prepaid balances
Distinguish a minimum invoice from a subscription with included usage. A minimum invoice may establish a spending floor; an allowance may cover a defined quantity before overage charges apply. Prepaid credits introduce separate questions about expiration, refunds, and unused balances.
For a plan whose allowance is deducted before overages, a useful structure is:
API invoice = fixed plan fee + chargeable overage + applicable add-ons
Only use this formula if it matches the contract. Do not add the same included usage twice or assume all plans apply marginal pricing in the same way.
Long-running shipments and repeat registrations
Long monitoring periods increase lookup volume in a polling design. Under per-shipment pricing, the relevant question is whether the original fee covers that duration. Test exceptions and delayed shipments, not just deliveries that finish quickly.
Also confirm what happens when the same tracking number is submitted twice, corrected, deleted and re-added, or associated with a different carrier. Implement duplicate prevention where appropriate, but do not assume application-level deduplication perfectly matches the supplier's billing identity.
Rate limits and peak capacity
An affordable monthly allowance does not establish that an integration can handle a large import or traffic spike. Check request-rate limits, batch limits, concurrency restrictions, and the expected behavior when limits are reached. A plan that meets monthly volume but cannot support the required workflow is not a like-for-like alternative.
Engineering and operating costs
Keep the API invoice separate from total ownership cost. Internal expenses may include integration development, webhook hosting, queues, monitoring, incident response, data storage, and maintenance.
Use your own labor and infrastructure estimates. A more expensive subscription may still be economical if it demonstrably reduces operational work, but that saving should be tested rather than assumed.
How to compare quotes and validate a shortlist
Ask each supplier to price the same workload specification: parcel volume, shipment mix, monitored duration, update requirements, endpoints, peak load, and required services. Request a written explanation of the billing unit and a sample invoice calculation.
For teams considering 17TRACK, the official Tracking API page and API documentation are the relevant starting points for product and integration evaluation. Confirm the applicable pricing and billing definitions directly before assigning a model in your forecast. This article does not quote or classify a current 17TRACK plan.
Before committing, run a controlled pilot using representative shipments. Include split orders, duplicate submissions, delayed parcels, cross-border movements, and shipments that cross a billing boundary. Only test failure or retry behavior in ways permitted by the service.
- Compare your request logs with the supplier's usage records.
- Reconcile registered tracking units with billed shipment units.
- Check whether the required update cadence is actually achieved.
- Measure peak demand separately from monthly consumption.
- Investigate unexplained differences before extrapolating costs.
Build at least three forecasts: normal operations, seasonal peak, and prolonged transit. Change the underlying drivers rather than adding an arbitrary percentage to the bill. For example, model more parcels for a peak and longer monitoring durations for a delay scenario.
Which model should you choose?
Favor per-call pricing when lookups are infrequent, request demand is measurable, and the forecast remains below the break-even point after registrations and other billable activity are included. It is less attractive when frequent polling or unpredictable monitoring duration creates substantial request exposure.
Favor per-shipment pricing when continuous monitoring is required and the quoted shipment fee includes the update frequency, tracking duration, and delivery mechanism you need. It is less attractive when you pay for monitoring you rarely use or when the shipment definition creates unexpected additional units.
The final decision should use total cost per operational parcel: the API invoice plus attributable operating costs, divided by the unique parcels your business needs to monitor. Keep that internal parcel definition consistent across quotes, even when suppliers use different billing units.
FAQ
Are unsuccessful API requests billable?
Do not assume either outcome. Ask for the treatment of validation errors, authentication failures, rate-limit responses, server errors, and timeouts. A timeout can also create uncertainty about whether a request was processed before your application retried it.
Does one order always count as one shipment?
No. An order may contain several separately tracked parcels. For budgeting, map orders to tracking units and then apply the supplier's definition. Confirm how returns, replacements, and carrier handoffs are counted.
Will batch requests reduce my bill?
Only if the billing rules reward batching. Batches can reduce network requests without reducing chargeable tracking units. Verify the batch limit and whether billing applies per request, per item, or through a weighted unit.
Can webhooks eliminate all lookup requests?
They may remove much routine polling, but your design may still need initial retrieval, recovery after missed events, or periodic reconciliation. Include those calls in the estimate and confirm any charges for webhook delivery.
How should I budget for shipments still active next month?
For per-call pricing, forecast the requests those shipments will generate in the next period. For per-shipment pricing, confirm whether monitoring remains covered or triggers another charge. Do not count only newly created shipments when estimating ongoing workload.
Sources
The calculations above use explicitly hypothetical inputs, not published supplier prices. For a 17TRACK evaluation, use these official reference pages and confirm commercial terms directly:
