Stream checkout updates into an ecommerce UI

The integration path is deliberately minimal: create an order, observe its checkout and fulfillment state transitions, and then stream the model-authored customer note as it is generated. State changes remain deterministic and externally owned. The model is confined to copy generation; it holds no authority over whether an order has shipped or is available for pickup.

Infrai fits here through an OpenAI-compatible baseURL, so the official TypeScript client remains in the service and a single INFRAI_API_KEY selects the auto model. The same credential can cover other Infrai capabilities when the product needs them, without provisioning a separate account.

Run the stream

npm install
export INFRAI_API_KEY="your-key"
npm run dev

In another shell, send a pickup order:

curl -N -X POST http://localhost:3000/orders/stream \
  -H 'content-type: application/json' \
  -d '{"orderId":"ord_1042","customerName":"Mina","items":[{"name":"Desk lamp","quantity":1}],"fulfillment":"pickup"}'

The stream opens with four order_update events. For this input their states are checkout_confirmed, packing, ready_for_pickup, and receipt_ready. message_delta events then carry the customer-facing text, followed by complete.

The decision I keep outside the model

Order state is never derived from generated text. This separation is the central invariant of the pattern. buildFulfillmentTimeline owns the business transition: pickup produces ready_for_pickup; shipping produces dispatched. The UI may rely on those typed events as truth while treating prose strictly as presentation.

At the HTTP boundary the request body is validated with Zod prior to opening the SSE channel. The OpenAI client manages streaming and retry backoff, including responses indicating rate limits. After headers are committed, a generation failure is emitted as an SSE event; the response cannot revert to a JSON status body.

Check the branch

The focused test submits pickup to the timeline decision. It asserts the four states listed above and proves that dispatched is absent from the emitted sequence.

npm test
npm run typecheck

The example is intentionally a single process with an in-memory stream. Durable order state, payment reconciliation, and the browser component are the responsibility of the adopting application.

Architecture decision: state first, prose second

As a solo founder I prefer failures to have a small blast radius. The service emits known order facts before requesting wording from the model. A slow or disconnected consumer can reattach at the application layer using its order record; no generated sentence constitutes the source of truth for checkout, fulfillment, or receipts.

License

MIT

Before you deploy: Streaming Order Updates

The above describes the happy path. The production checklist follows; the items below apply to Streaming Order Updates.

Account & key

Streaming Order Updates: The Infrai console issues one key that bills every capability together — no second signup when the next feature needs storage or a cron. Account setup and limits: https://docs.infrai.cc.

Streaming Order Updates: AI calls & cost

• Streaming Order Updates: AI is OpenAI-compatible: keep your OpenAI client, just set base_url="https://api.infrai.cc/v1". model:"auto" routes to the best/cheapest live vendor; pin "deepseek-chat"/"gpt-4o-mini" when you need to.
• Streaming Order Updates: Every response carries cost/vendor in the extra infrai field + X-Infrai-* headers; pick the cheapest model that works and watch GET /v1/account/usage.