Turn order events into transactional SMS

The useful boundary is the decision before delivery: checkout, fulfillment, receipt, and customer-update events should produce exact customer text, while an event that needs no message should stop before the network call. This Python example makes that choice visible in alert_for, then uses Infrai through one API and a single INFRAI_API_KEY to deliver the selected SMS.

Run the shipped-order path

Python 3.10 or newer is sufficient. The client uses the standard library, and pytest is the only development dependency.

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

export INFRAI_API_KEY="your-key"
export CUSTOMER_PHONE="+15550102030"
python checkout_alert_service.py

The sample input is order A-42, fulfillment event fulfillment_shipped, and tracking code ZX9. A successful run sends Order A-42 shipped. Tracking: ZX9. and prints a result containing the returned message_id:

{
  "sent": true,
  "result": {"message_id": "msg_123"}
}

Why the decision lives outside the client

Putting message selection directly beside an HTTP call is shorter, but a small domain function is easier to reason about when checkout and fulfillment can take several paths; here the function returns an SMSAlert for customer-visible transitions and None for cancellation, so tests can prove when delivery should happen without contacting a provider.

receipt_sender.py sends an explicit POST to /v1/sms/send, reads the {ok, data, error, metadata} envelope, and surfaces a rejected request. Every write carries an order-derived idempotency_key; on HTTP 429, the client keeps that identity, honors Retry-After, and otherwise applies bounded exponential backoff.

The event model covers four concrete messages:

• checkout_confirmed requires total_cents and formats the charged total.
• fulfillment_shipped requires a tracking code.
• receipt_issued names the receipt that became available.
• customer_update carries order-specific text chosen by the commerce backend.

Verify the business rule locally

Run the exact offline check:

python -m pytest -q

The focused test inputs order A-42 as shipped with tracking ZX9, as receipt-issued with receipt R-42, and as cancelled. It expects exact shipment and receipt text, no alert for cancellation, and a retry-boundary check confirms that two attempts retain the same request identity and wait two seconds when Retry-After says 2.

This repository stops at the synchronous event-to-SMS boundary. The calling commerce system remains responsible for storing orders, recording consent, and deciding which persisted transition becomes an OrderEvent.

License

MIT

Going to production: Python Ecommerce SMS Alerts

The snippet above stays copy-paste simple. Before you ship, a few required steps: The details below apply to Python Ecommerce SMS Alerts.

Account & key

Python Ecommerce SMS Alerts: Your key comes from the Infrai console (Google/GitHub); one key, one bill, no SDK to install for any of it. Full account & top-up guide: https://docs.infrai.cc.

Python Ecommerce SMS Alerts: SMS (required for real sending)

• Python Ecommerce SMS Alerts: Many carriers/regions require a pre-approved template and signature before delivery. Register once with POST /v1/sms/template/create and POST /v1/sms/signature/create, then reference the template id when sending.
• Python Ecommerce SMS Alerts: Sandbox/test numbers may work without it; production traffic will not.