GET /fulfillment-availability and GET /fulfillment-availability/times resolve an account's occurrences after a shipping method and provider department are known. Order Planner uses these operations. A fulfillment date and an optional usage date are distinct; clients must retain the occurrence pair when reading times.
Each occurrence carries the delivery date's calculated order deadline, including applicable shipping preparation rules. Order Planner uses plan_edit_deadline=same_as_first_day to show the first displayed day's deadline for the period; none suppresses the period deadline. Without an explicit setting, a period deadline is shown only when the planner has one displayed day.
POST /fulfillment-availability/options is a read-only companion operation. It evaluates proposed context without loading, creating or saving a cart, order, payment or calendar period. POST keeps address and proposed lines out of query strings. It does not authorize a subsequent purchase: cart writes and checkout revalidate eligibility and quote evidence.
Query scope is program_id or program_slug, with optional client_account_id. An explicit account must be the authenticated selected account; an implicitly selected account supplies its own program. Account-free discovery uses program eligibility. Account address defaults are read through customer resolution; a proposed address overrides them for this evaluation only.
The JSON body requires time_cycle_period_id, a positive active period in the program's default cycle. Optional inputs are fulfillment_kind (delivery or collect), shipping_method_id, payment_method_id, provider_department_id, delivery_address (address_line1, postal_code, city, country_code), delivery_date and lines (product_id, positive integer quantity). Products are optional; malformed/duplicate products are rejected rather than interpreted as an empty selection. Variant selections are outside this operation's contract and are rejected. No external offer identity is accepted.
The response contains:
state: available, input_required or no_options. Backend/source failures use HTTP problem responses, never an unrestricted result. Loading is a client request state.fulfillment_kinds: candidate kinds in the authorized scope, including a kind awaiting address input. This allows pickup/delivery choice before entering a delivery address.required_inputs: missing prerequisites such as delivery_address; when both kinds exist, an address requirement for delivery does not block pickup options.options: shipping-method and department identities/titles, provider time zone, eligible delivery_dates and delivery_windows. Explicit departments are not silently substituted. Equivalent resolved method/department pairs are deduplicated.Dates are provider-local ISO calendar dates within the requested period. Time windows are computed for the first available date, or for the supplied delivery_date; other dates have date-only windows. Repeat discovery with the selected context/date to obtain its times before creating a cart. The existing planner /times operation retains its separate usage-date contract.
Discovery delegates to the same transient evaluator as cart checkout. Period-bound cart dates pass through IFulfillmentAvailabilityResolver.ResolveForOrder, which applies account shipping relations and schedule occurrences while retaining the transient order's products, program, address and shipping duration. Source offer/customer openness, local purchasing eligibility and the product-set intersection narrow those dates. Product-free source discovery requires at least one uniquely available, quotable product on each returned date. Cached catalog facts do not replace cart or checkout validation. Identical method/department evaluations are shared only within one discovery invocation. Each scoped period evaluation reads source offers/customer eligibility and ordering-week openness once, then applies local product rules separately for each date. Source quotes use the local catalog resolver's focused product-eligibility read: the same category/account, publication/source, stock, purchasing and delivery rules apply without projecting unrelated products, media, food information or local prices. The snapshot is bound to its account, program, department and period; every new evaluation and cart/checkout request reads its own source facts. Final checkout retains its cache-bypassing quote read.
Deployment requires rebuilding/restarting Platform. There are no properties or schema migrations for this capability. The first-add UI and recurring account weekday preferences are separate consumers/work.
Cart GET responses that refresh source-backed evaluation and newly applied cart POST responses include a standard Server-Timing header. It separates context resolution, departments/address-aware duration, source quotes, pricing, shipping-method candidates, payment methods and delivery dates. Durations are milliseconds; the shipping description contains only a candidate count. Timings describe the response's evaluation, exclude transport/serialization and persistence overhead, and are not cart state or persisted quote evidence. Duplicate-write responses and reads that reuse a projection omit evaluation timings. No customer data, source identifiers or credentials are included.