Docs
Firmly Agentic Commerce
Docs
Set theme to dark (⇧+D)
  1. Docs
  2. Solutions
  3. ...
  4. Use Cases
  5. Scheduled or Triggered Buying Agent

Scheduled or Triggered Buying Agent

The user sets a standing rule and the agent acts on it without re-asking each time:

  • “Restock my coffee every 4 weeks”
  • “Buy this jacket if it drops below $120”
  • “Reorder my dog’s food when I’m running low”

The destination owns the scheduler, the trigger, and the rule storage. Firmly executes the commerce side of each cycle — discovery, cart, payment, order placement — using saved payment credentials and the user’s saved address.

​​ What Firmly does (and doesn’t) for this scenario

Layer Owner
The schedule / cron / event listener Destination — Firmly has no native subscription or recurring-order API
The trigger condition (price drop, inventory threshold, time elapsed) Destination
The user’s standing-rule policy (spending cap, frequency limits) Destination
Each individual order’s discovery, cart, payment, and order placement Firmly
Enrolled card for reuse Firmly — via Agentic Pay
Saved address Destination stores it; Firmly accepts it in set-shipping-info

Firmly alone can’t support this scenario — the scheduler must live on your side. If the destination doesn’t have one, build it first.

Choice Default Why
Integration pattern Deep Link / Headless No UI — the agent runs in the background and just calls APIs
Auth Server-to-server The scheduler is backend; S2S is the right shape
Payment Agentic Pay Enroll the card once, then reference it each cycle with Select Card; unattended cycles add a mandate at Create Intent (see the boundary note below)

​​ API sequence (per cycle)

# Endpoint Purpose
1 (none) Destination’s scheduler fires
2 Server-to-server auth header Identify the user/device for this cycle
3 (optional) Discovery search Re-resolve product (price-drop trigger may have driven discovery already)
4 Add line item Build the cycle’s cart
5 Set shipping info Reuse the user’s saved address; populates the shipments array with shipping_method_options
6 Get shipping availability (Optional) Delivery dates / time slots / pickup locations
7 Set shipping method Pick a default method from the shipment’s shipping_method_options (often the cheapest for replenishment)
8 … then the checkout + Agentic Pay tail Get/set consents → set billing info, then pay against the built cart with Agentic Pay: Select Card → Create Intent → Wallet Complete Order. Because the cycle’s cart was built above, finalize against it, not the one-shot place-order. See the single-product flow for the cart-building phases

At order placement, pay against the user’s enrolled card through Agentic Pay — Select Card references the stored virtual_card_id, and unattended cycles add the per-cycle mandate at Create Intent. The documented complete-order request takes a fresh encrypted card, not a saved-token field, so saved-card reuse runs through Agentic Pay (see the boundary note above).

Use a fresh Idempotency-Key per cycle so retries don’t double-place. (The Idempotency-Key header is honored on the UCP bridge; on core REST complete-order, guard against double-placement on the destination side.)

​​ Agent considerations

  • Confirm before the first cycle. Even if subsequent cycles are silent, the first time a recurring rule fires, surface the order to the user before placing. The user may have changed their mind.
  • Spending caps. Implement a per-transaction and per-period cap on the destination side. Firmly enforces no caps by default — see Consent & Disclosure.
  • Stock and price changes. A scheduled order can fail at order-placement time if stock dropped or the price changed materially. Decide policy in advance: silent retry next cycle, fall back to a similar product, or notify the user.
  • Revocation. The user must be able to cancel the rule in conversation at any time. Firmly does not own the rule; the destination does.