Reference · built on requestOperator by FibricOrders & fulfillment

Promise Date

Reads the date each open order was promised against lead time, carrier transit, and holidays, then proposes new dates and notices.

Request accessPricing ↗

About

The date shown at checkout goes stale the moment a warehouse slows down or a holiday lands in the window. Promise Date reads the date each open order carries, the time your locations take from order to ship, the carrier's transit figure for the lane and ship date, and the public holidays on both ends.

For every order it recomputes the arrival date and compares it with the promise. Where the new date is later, it proposes a slip notice, or a service upgrade when a faster service restores the original date. A person approves the batch. The order keeps the old date, the new one, and the inputs behind it.

This is a reference listing. It documents what Fibric would read from Promise Date and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Open orders with the delivery date or window shown at checkout and the service the customer chose, from Shopify or WooCommerce
  • The fulfillment order's status and assigned location, and the time from order to shipDate on ShipStation shipments from that location
  • UPS Time in Transit responses: businessTransitDays and deliveryDate for the origin, destination, and shipDate
  • FedEx transit times for the same lane from the Rates and Transit Times API
  • EasyPost rate fields delivery_days, delivery_date, and delivery_date_guaranteed when labels are bought there
  • Public holidays for the origin and destination countries from Nager.Date or OpenHolidays
  • Shipments already in transit whose carrier delivery date has moved

Proposed actions

  • Target capability: propose a recomputed arrival date per open order from lead time, transit days, and the holiday calendar
  • Target capability: propose a slip notice for orders whose recomputed date is later than the date shown at checkout
  • Target capability: propose an upgrade to a faster service when it restores the promised date, with the rate difference shown
  • Target capability: propose updating the estimated date on the order so support sees the same number the customer does
  • Target capability: propose a Postmark email or a help desk reply carrying the new date

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Recompute after a holiday lands in the window

    When a public holiday from Nager.Date falls between shipDate and the UPS deliveryDate, propose the new date and the notice for every order that crosses it.

    With Holidays & FX Reference, UPS

  • Upgrade the order instead of apologising

    When FedEx transit for a faster service restores the checkout date on a Shopify order, propose the upgrade with the cost difference for approval.

    With FedEx, Shopify

  • Give support the same number first

    Before notices go out, propose the updated estimate on the WooCommerce order and an internal note, so a where-is-my-order reply matches the Postmark email.

    With WooCommerce, Postmark

Requirements

  • Orders that carry the date or window shown to the customer at checkout, in a field you can name
  • A source of fulfillment lead time per location: shipment history in ShipStation, or a value you maintain
  • Carrier transit time: UPS Time in Transit, FedEx Rates and Transit Times, or EasyPost rates
  • A holiday source for the countries you ship from and to: Nager.Date or OpenHolidays
  • Your notice rule: how many days of slip triggers a notice, and who approves service upgrades
Authentication
Store, carrier, and email connectors each keep their own credential: a Shopify or WooCommerce API key, UPS and FedEx OAuth client credentials, and a Postmark server token.

Limits

  • Carrier transit figures are estimates for the lane and date; only a guaranteed rate carries a committed date
  • Lead time is a history, not a promise; a warehouse that is behind today shows up only as shipDates move
  • Holiday feeds cover public holidays; a carrier's own non-operating days are read from the transit response where the carrier reports them
  • It recomputes dates; it does not change a service or buy a label without approval

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Promise Date ↗

Questions and answers

What does the batch look like to the approver?
A batch of recomputed dates and the notices that go with them. Each line shows the checkout date, the lead time used, the carrier transit figure and its source, the holidays counted, and the proposed date.
What does the order keep?
The order holds the old and new dates, the inputs behind them, the notice sent or withheld, the approver, and the time. A later recomputation is appended; the history is never overwritten.
Where does it stop?
Send a notice, change a shipping service, buy a label, or edit an order. When the carrier returns no transit figure for a lane, the order is flagged rather than given a date.
Ask about Promise Date

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy