Skip to main content
Jump to a use case:

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 standalone POST /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

The predictions 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.
Timezone caution: A UTC value of 2026-05-03T03:00:00Z is May 2nd in America/Los_Angeles. Do not read the date directly from the UTC string — always convert first.
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 use estimated_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

Pass latest_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

Service levels that cannot deliver by May 3 (UTC) are omitted from the response. Only eligible service levels are returned in predictions.

Response

Service levels that would have arrived after May 3 — such as UPS Ground — are not present in the response.

Filter by required delivery date

If your deadline is expressed as a local date rather than UTC, filter the predictions 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 alongside POST /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:
  1. POST /v2/estimates — returns delivery date predictions for all (or a filtered set of) service levels.
  2. POST /shipments — returns rates with pricing for all connected carriers.
Join on 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
Step 2 — Get rates and pricing
Step 3 — Join on servicelevel.token
Sort by price to find the cheapest option, by transitDays to find the fastest, or filter on deliveryDate to find the cheapest option that meets a target date before presenting options to customers.

Provide conservative commit dates for regulated or time-critical shipments

Use confidence_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

Each confidence_level corresponds to a percentile of historical delivery performance on the origin-to-destination lane.

Request

Response

The confidence_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

Shippo Estimate dates are ML-powered predictions, not contractual guarantees. For absolute delivery guarantees with carrier backing, use services such as USPS Priority Mail Express or FedEx First Overnight and confirm money-back guarantee terms with the carrier.

Inform warehouse systems of the ideal ship-out date

Use planned_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 call POST /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 the planned_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, extract planned_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

The planned_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.
For orders with tight fulfillment windows, consider calling the Estimate API with confidence_level: "HIGH"(see Provide conservative commit dates) so the predicted delivery date accounts for real-world variability before you commit it to the customer.
Last modified on October 2, 2026