PromisePro is a service that answers one question for any item, anywhere: can we get it to this shopper fast — and exactly when will it arrive? Give it an item, a quantity, and a destination ZIP, and it returns the order-by cutoff time and the resulting delivery date from the fastest fulfillment center that can actually ship it.

It's built to power delivery promises on storefronts — the "Order within 4h 12m → arrives Tuesday, Jun 24" badge that turns a vague "ships soon" into a concrete, trustworthy commitment at the moment of purchase.

It shows an exact date+countdown for genuinely fast items, a "Get it between X–Y days" window for moderately fast items (under 7 transit days), and nothing otherwise — never a weak or misleading promise beyond that window.

What it does

Behind a single request, PromisePro:

Finds which fulfillment centers (FCs) currently have the item in stock (at least the requested quantity).
Looks up shipping routes from those FCs to the shopper's ZIP.
Picks the fastest viable option, and if today's order cutoff has already passed, rolls forward to the next day that can still deliver — so the cutoff it returns is always in the future.

The request and response, at a glance:

GET /v1/delivery-estimate?item_id=ABC123&qty=1&destination_zip=75087

{
  "cutoff_time": "2026-06-24T00:00:00Z",
  "estimated_delivery_date": "2026-06-26",
  "transit_days": 2
}

If the item can't be promised — out of stock, no route to that ZIP, or unknown item — it returns a clear status instead of a guess. It never invents a delivery date.

Bundles: one promise for several items

Selling one listing that ships as several components (a bundle whose parts move as individual items in Spreetail's system)? Send them all in a single request and PromisePro returns one combined promise for shipping them together:

POST /v1/delivery-estimate

{
  "postalCode": "75087",
  "items": [
    { "spin": 427936, "qty": 2 },
    { "spin": 427937 }
  ]
}

The bundle ships on a single shared order date — the earliest day on which every component is orderable — and the response is the same { cutoff_time, estimated_delivery_date, transit_days } shape as the single-item call: the most-binding (earliest) cutoff, the latest component arrival, and the slowest component's transit. It's all-or-nothing — if any one component can't be promised, the whole bundle returns that status rather than a partial promise. (qty is optional and defaults to 1; a single-item bundle is identical to the equivalent single-item request.)

Two ways to use it

1. The drop-in widget (recommended). A small, self-contained script renders the delivery-promise badge on a product page, calls the API for you, and shows the live countdown — only when the delivery is genuinely fast. It's fail-closed: if anything is off, it shows nothing rather than a weak or misleading promise.

Developer Guide — embed the widget on any storefront (Shopify, BigCommerce, custom, headless): attributes, theming, environments, troubleshooting.
Shopify Setup (for merchants) — a non-technical, ~15-minute walkthrough to turn the badge on in a Shopify store.

2. The API directly. Call GET /v1/delivery-estimate from your own front end, app, or back-office tooling.

API Reference — parameters, response shape, and status codes.

Good to know

It never overpromises. A delivery date is returned only when an FC both stocks the item and has a fast-enough route to the ZIP; otherwise the caller gets a clear "no estimate" status.
US-only today. Destination is a 5-digit US ZIP.
Public and rate-limited. The widget endpoint is open (no key) and capped at 100 requests/second, with CORS enabled for in-browser use.
Always current. Inventory and routes refresh continuously from the systems of record, so estimates reflect what's actually sellable and shippable now.

Where to start

Selling on Shopify and want the badge live fast → Shopify Setup (for merchants).
Embedding on another platform or a custom site → Developer Guide.