- Display a delivery date on a product detail page, cart, and checkout
- Filter carriers or service levels that miss a required delivery date
- Power rate shopping decisions across multiple service levels in a single call
- Provide conservative commit dates for regulated or time-critical shipments
- Inform warehouse systems of the ideal ship-out date
Display a delivery date on a product detail page, cart, and checkout
Show customers exactly when their order will arrive, before they buy.Displaying an expected delivery date at every step of the shopping journey reduces uncertainty, builds purchase confidence, and cuts down on “Where’s my order?” support tickets. Shippo Estimate returns an ML-powered
estimated_delivery_date_utc for each service level, so you can surface a real calendar date, not a vague transit window, wherever your customer sees shipping options.
How it works
The Estimate API is a standalonePOST /v2/estimates endpoint. It returns ML-powered predicted delivery dates across carriers and service levels. It does not return pricing. For use cases that require both delivery dates and rates, call POST /v2/estimates and POST /shipments separately and join the results on servicelevel.token.
Call POST /v2/estimates with the origin ZIP, destination ZIP, parcel dimensions, and the planned ship date. The response includes a predictions array with one entry per service level, sorted fastest first. Each entry contains estimated_delivery_date_utc, which you convert to the destination’s local timezone before displaying.
You can call this endpoint at multiple points in the shopping flow:
- Product detail page Use the customer’s saved or estimated destination ZIP to show an expected delivery range next to each service option.
- Cart Re-call the endpoint when the customer confirms their shipping address to refresh the dates.
- Checkout Display the selected service level’s predicted delivery date in the order summary before the customer confirms payment.
Request
Create an Estimate with the origin zip and the customer’s destination zip. The estimate object is returned.Response
Thepredictions array returns one entry per supported service level, sorted fastest first.
Display example
estimated_delivery_date_utc is in UTC. Always convert to the destination timezone before displaying.
The Estimate API does not return pricing. To display rates alongside delivery dates, call
POST /shipmentsseparately and join on servicelevel.token. See Power rate shopping decisions for a combined flow example.Filter carriers or service levels that miss a required delivery date
Some orders have hard delivery requirements: same-day gifts, event merchandise, subscription boxes with commit dates. Rather than presenting all available rates and hoping customers pick correctly, you can useestimated_delivery_date_utc to filter out any service levels that would miss the required date before displaying options or purchasing a label.
How it works
Passlatest_delivery_date in the request body. The API compares this date against the UTC date component of each prediction’s estimated_delivery_date_utc and silently omits any service level whose estimate falls after the specified date. Only service levels that can meet the deadline appear in predictions.
Timezone note:
latest_delivery_date is compared against the UTC date component of each estimate — not the local delivery date. If your deadline is expressed in a non-UTC timezone, apply the filter client-side after converting estimated_delivery_date_utc to the destination timezone. See Filtering Results for full details.Request — using latest_delivery_date
predictions.
Response
Filter by required delivery date
If your deadline is expressed as a local date rather than UTC, filter thepredictions array yourself after timezone conversion.
Purchasing a label: The Estimate API returns no pricing. Once you have the eligible
servicelevel.token values, pass them to POST /shipments (optionally with carrier_accounts) to retrieve rates, then purchase a label via POST /transactions.Power rate shopping decisions across multiple service levels in a single call
Compare delivery dates across all supported carriers at once, then join with pricing to find the best value. The Estimate API returns predictions for every supported service level in a single request, sorted fastest first. Because it returns no pricing, use it alongsidePOST /shipments — join the two responses on servicelevel.token to build a complete picture of both delivery date and cost for each option.
How it works
Make two calls:POST /v2/estimates— returns delivery date predictions for all (or a filtered set of) service levels.POST /shipments— returns rates with pricing for all connected carriers.
servicelevel.token to assemble a combined rate-shopping view.
To limit Estimate results to specific service levels, pass servicelevel_tokens. To limit Shipments results to specific carriers, pass carrier_accounts.
Step 1 — Get delivery date predictions
servicelevel.token
Provide conservative commit dates for regulated or time-critical shipments
Useconfidence_level: "HIGH" to get delivery dates that are more reliable — not just most likely.
For regulated shipments (pharmaceuticals, medical devices, age-restricted goods) and time-critical orders (event tickets, perishables, SLA-bound fulfillment), committing to a delivery date that is missed has real consequences. Passing confidence_level: "HIGH" returns a more conservative predicted date — one where historically only 5% of shipments have arrived later — so you only surface dates you can reliably stand behind.
How confidence levels work
Eachconfidence_level corresponds to a percentile of historical delivery performance on the origin-to-destination lane.
Request
Response
Theconfidence_level field in the response echoes back the level used. At GA, HIGH will return later, more conservative dates than DEFAULT for the same service level on the same lane.
Selecting a service level for a commit date
Inform warehouse systems of the ideal ship-out date
Useplanned_ship_date and estimated_transit_days together to schedule warehouse tasks and enforce fulfillment cutoffs.
Knowing a predicted delivery date is only useful if your warehouse knows the latest date an order can be picked, packed, and handed to the carrier to achieve it. The Estimate API’s planned_ship_date is the ship-out date you are committing to, and estimated_transit_days tells you the transit window from that date. Together they enable automated warehouse task creation, pick queue prioritization, and same-day cutoff enforcement.
How it works
When you callPOST /v2/estimates, pass the planned_ship_date that reflects your intended handoff to the carrier — typically today’s date at the warehouse’s daily carrier pickup or drop-off cutoff time. The response echoes planned_ship_date back in UTC and returns estimated_transit_days on each prediction, so you can calculate and display the full fulfillment timeline.
For warehouse scheduling, planned_ship_date is the ship-by target. Your system must create and complete the pick/pack task before that datetime.
Request
Pass the warehouse cutoff time as theplanned_ship_date. In this example, the warehouse closes carrier handoffs at 3:00 PM PDT (22:00 UTC).
Response
Push tasks to your warehouse system
Once the customer selects a service level at checkout, extractplanned_ship_date and estimated_transit_days from the matching prediction and send them downstream to your warehouse management system (WMS) or fulfillment queue.
Enforce carrier cutoff times
Theplanned_ship_date you pass into the request defines the cutoff. If an order is placed after your warehouse’s daily carrier handoff time, bump planned_ship_date to the next day’s cutoff (skip days your warehouse is closed) and re-call the endpoint — the delivery date predictions will update accordingly.