Order promising, delivered by the Pipe17 Estimated Delivery Date (EDD) service, is an API that returns delivery date options before a shopper buys. You send a destination and the items you want a promise for, and the service returns ranked options with a promise date for each one.
The request can be small. A single product and a postal code is enough to get a promise, which is what makes this work on a product detail page as well as in a cart.
Every response is calculated from your own operational data in the app:
- On-hand inventory at each active fulfillment location
- Expected arrivals of inbound inventory, when enabled
- Daily capacity at each location
- Carrier services enabled for your organization and zone-based transit times
- The schedule assigned to each location, which supplies the time zone, carrier pickup cutoffs, and closure dates
The service builds three kinds of fulfillment plan: ship now from one location, ship now from several locations, and wait at one location for inbound stock to arrive.
This article covers what order promising needs before it can return accurate dates. To surface those dates in your storefront, see the Pipe17 Estimated Delivery Date Service Reference.
Where you can use it
The API takes items and a destination. It does not require a cart, a session, or a shopper identity, so you can call it anywhere in the buying journey.
| Surface | What you send | What the shopper sees |
|---|---|---|
| Product detail page | One SKU, quantity one, and a postal code the shopper enters or you detect | A promise for the item they are looking at, before it reaches a cart |
| Category or listing page | One SKU per item shown, with a postal code | A promise on each card, though this means one request per item |
| Cart | Every SKU and quantity in the cart, with a postal code | A promise for the whole cart, including split and wait options |
| Checkout | The cart contents and the confirmed shipping address | A promise per shipping method the shopper can choose between |
| Agentic or headless channels | The same items and destination | A promise returned to whatever is asking, with no storefront involved |
The product detail page is the highest-value placement for most brands, because it answers "when will this arrive" at the moment the shopper is deciding, rather than after they have committed to a cart. It is also the simplest integration: one SKU, one postal code, one call.
Split and wait options only become meaningful once more than one item is in play, so a single-item request typically returns straightforward single-location options.
What order promising is and is not
Understanding the boundaries of the service prevents most implementation surprises.
| It is | It is not |
|---|---|
| A layer on top of a configured Pipe17 org | A standalone product. The service holds no data of its own. Everything it uses is a transformed copy of data already in the app. |
| An API that returns delivery date options | A user interface. Nothing displays to shoppers until you embed the API into your selling channel. |
| A service Pipe17 enables for your org | A self-serve connector. You cannot add or enable the EDD connector yourself. |
| A pre-purchase estimate based on your current configuration | A live carrier rate or tracking lookup. The service uses zone-based transit times, not real-time carrier API calls. |
Two consequences are worth stating plainly:
- Order promising depends on an existing, configured org. Your locations, schedules, products, and inventory must already be accurate in the app. If configuration is missing, the service returns fewer options rather than guessing at a date.
- Nothing appears in your storefront automatically. You build the front-end integration that calls the API and renders the result on product detail pages, cart, or checkout.
How it works
- Pipe17 sets up the EDD connector on your org and configures its settings with you.
- The connector polls the app on a schedule and pushes locations, schedules, carrier services, products, inventory, arrivals, and shipments into the service.
- Your storefront or backend calls the API with the items and the shopper's destination.
- The service resolves each location's schedule, filters to locations that can cover the request, applies capacity, pickup cutoffs, closures, and transit times, and builds fulfillment plans.
- The service returns the surviving options with a promise date, an estimated number of days, and a rank.
Because the connector syncs on a schedule, configuration changes you make in the app take effect on the next sync cycle rather than instantly.
Before you begin
Confirm the following before requesting order promising for your org:
- An active Pipe17 org with fulfillment locations already set up
- A complete address on each location, including a valid postal code
- A schedule created for each location, or an organization default schedule to fall back on
- Products active in the app, with SKUs that match what your storefront sends
- Inventory syncing into the app from your warehouses, stores, or 3PL partners
- Shipments flowing into the app, which the service uses to measure current-day capacity utilization
- Development resources available to embed the API into your selling channel
Schedules
A schedule is a separate entity in the app, not a set of fields on a location. It defines:
| Field | What it holds |
|---|---|
| name | A human-readable name, unique within your organization |
| timezone | IANA time zone identifier, such as America/New_York. Determines when a cutoff falls in local time. |
| windows | Recurring weekly windows. For a carrier pickup cutoff schedule, each window runs from midnight to that day's cutoff time, and a day with no window means no carrier pickup that day. A schedule used for pickup cutoffs must have at most one window per day. |
| scheduleExceptions | One-off closures on a specific date or a recognized US federal holiday symbol, such as US/thanksgiving |
You create a schedule once and assign it to as many locations as need it. Editing the schedule updates every location that references it, with no per-location change required.
How a location gets its schedule
Each location carries a reference, carrierPickupCutoffScheduleId, rather than schedule data of its own. At request time, the service resolves that reference:
- Time zone and weekly cutoffs come from the location's own schedule. If the location has none, they come from the organization default schedule set on the EDD integration.
- Exceptions follow override-or-inherit. The location's own schedule wins whenever it defines an exception list, including an explicit empty list, which means the location observes no closures. When the list is unconfigured, the location inherits the default schedule's exceptions.
- A location that resolves to no schedule at all has no usable time zone or cutoffs and is skipped for that request. It is not removed from the app or marked inactive. It simply produces no delivery options, even when it is active and holds inventory for every item requested.
Two behaviors to plan around:
- Exceptions marked as closed shift the estimate. Exceptions that set special or reduced hours are stored and synced but are treated as normal working days in this version.
- A schedule with no resolvable IANA time zone is not synced to the service. A location pointing at it falls back to the default schedule, or is skipped when there is no default.
Location settings the service uses
| Setting | What it does | Effect when missing |
|---|---|---|
| Status | The location must be active in the app. | Non-active locations sync as inactive and are excluded from delivery options. |
| Address, including postal code | The service uses the first three digits of the postal code to look up transit times. | The location still syncs, but the service cannot find transit data for it, so it produces no options. |
| carrierPickupCutoffScheduleId | Assigns the carrier pickup cutoff schedule. | The location falls back to the organization default schedule, or is skipped when there is none. |
| locationCarrierServiceConfigs | Enables or disables individual carriers and service levels at this location, and can assign a carrier-specific cutoff schedule. | The location uses the organization's enabled carrier services and its own default schedule. |
| capacityLimits.maxNewOrdersPerDay | The daily order limit used for capacity checks. | The location is treated as having no capacity limit. |
| eddReceivingBufferDays custom field | Overrides the organization receiving buffer for inbound stock at this location. Accepts a whole number of days, zero or greater. | The organization setting applies. |
How capacity affects results
The service counts the shipping requests created at a location during the current local calendar day and compares that to the location's daily limit:
- Below the limit: no change to the estimate.
- At or above the limit: the service adds one day to the delivery time.
- At or above twice the limit: the service removes the location from consideration entirely.
A location with no capacity limit set is never throttled or removed on capacity grounds. Setting a realistic limit is what keeps promises honest during peak periods.
Organization settings
Pipe17 configures these on the EDD integration during setup. Review them with your account team rather than assuming defaults.
| Setting | What it controls |
|---|---|
| sellingChannelIntegrationId | The selling channel integration the service serves. Required. Without it, the connector does not sync. |
| carrierServices | An allow-list of carrier and service level pairs available for promises. It is empty by default, so no service is available until the pairs you use are added. A location-level setting overrides it. |
| maxSplits | The maximum number of splits the service may use, from 0 to 2. Defaults to 2. A request can ask for fewer, never more. |
| defaultScheduleId | The organization default schedule, used by any location without one of its own. |
| receivingBufferDays | Calendar days between an expected arrival and the stock being ready to ship. The connector sets this to 2 at setup. The service has no fallback of its own, so the value has to be present here or on the location. |
| inboundLookaheadDays | How far ahead the service considers expected arrivals. Defaults to 60 calendar days. |
| productsTags | Limits which products are in scope for promises. Empty by default, which puts no tag restriction on the product feed. |
| inventoryOrgWideLocations | When on, inventory syncs from every active, non-paused, non-excluded location in the org. When off, only inventory from fulfillment locations merged with the selling channel syncs. Off by default. |
| Per-entity sync toggles | Control which feeds sync: locations, schedules, products, inventory, arrivals, and shipments. Only the schedules feed is on by default. Every other feed, locations and inventory included, has to be turned on during setup. |
Example
Your organization enables UPS Ground and UPS 2nd Day Air in carrierServices, and sets a default schedule that observes seven federal holidays with a 2 PM weekday cutoff in Eastern time.
- Your Reno warehouse has its own schedule with a 4 PM Pacific cutoff and no exception list configured, so it inherits the seven holidays from the default schedule.
- Your Boston store has its own schedule with an explicit empty exception list, so it stays open on every holiday.
- Boston also has a location carrier service config disabling UPS 2nd Day Air.
A shopper on a product detail page on Thanksgiving, checking a single item against a Massachusetts postal code, sees a UPS Ground promise sourced from Boston. Reno returns nothing that day.
Inbound stock and wait options
When the arrivals feed is enabled, the service can build a plan that waits for inbound stock at a single location instead of splitting across locations. An arrival contributes only when its status is expected or shipped, its destination is an active location, its SKU matches the request, and its expected date falls inside the lookahead window.
Stock from an arrival is ready after the receiving buffer:
expected arrival date + receiving buffer days = inventory ready date
The location override wins when it is set. If neither the location override nor the organization setting is a valid whole number of days, the service does not build a wait option for that location. The buffer is not optional, and there is no built-in value behind it.
Wait options are labeled with a fulfillment strategy of waitForConsolidation in the response, so you can present them as a distinct choice. Split plans use on-hand stock only.
How options are ranked
The service sorts options by earliest promise date, then fewest splits, then fewest locations. Ranking is not purely fastest-first. It also protects choices the shopper needs to see:
- The fastest single-location ship-now option is preserved even when a split would arrive sooner.
- When a wait option exists and the request allows at least two options, the service reserves one place for the best ship-now option and one for the best wait option, so the caller can compare shipping now against waiting for one complete shipment.
Ranks are assigned starting at 1 after the final list is sorted.
Getting order promising enabled
The EDD connector is not available in the connector catalog and cannot be added by an admin in your org. Pipe17 sets it up for you.
- Contact your Pipe17 account team to request order promising.
- Attend a scoping call. Pipe17 reviews your fulfillment network, confirms your locations, products, and inventory are ready, and identifies any carriers that need to be added.
- Create a schedule for each location, or a single default schedule, and assign it.
- Pipe17 enables the EDD connector and configures the organization settings with you, including the carrier service allow-list.
- Confirm the first sync completes and your locations and schedules appear in the service.
- Build your front-end integration using the reference implementation.
Surfacing promises to shoppers
The service returns data. Rendering that data is your responsibility.
Your integration needs to:
- Call the endpoint with the selling channel integration ID, the destination postal code and country, and the SKUs and quantities you want a promise for
- Decide how the shopper supplies a destination on each surface. A product detail page usually needs a postal code field or a detected location, since there is no shipping address yet.
- Handle an empty options response, which means no fulfillable option exists for that destination
- Handle a validation error separately, which is what an unresolved or inactive SKU returns rather than an empty list
- Render the returned dates in your product detail page, cart, or checkout template
- Keep your API credentials server-side rather than in browser code
For a working Shopify example that covers the app proxy pattern, request and response formats, and product and cart page widgets, see the Pipe17 Estimated Delivery Date Service Reference. Adapt it to your theme and production requirements. Pipe17 does not provide a prebuilt storefront app.
Need Help?
If you need additional assistance:
- Use Ask Pippen, our AI agent, located at the top of the app page.
- Submit a support request with as much relevant detail as possible. Learn how to submit a request.
Contact Pipe17 support when:
- A location is fully configured with a schedule and still returns no delivery date after a completed sync cycle
- You use a carrier that is not available in the carrier service allow-list
- The connector shows sync errors you cannot resolve from the integration logs
- Response times or availability do not meet what your storefront requires
We're here to help you succeed with your operations.
Comments
0 comments