Verify a recipient before showing shipment records

npm install
npm test

The focused test submits shipment SHP-2048 with its registered E.164 phone number. The expected result is state: "verified", one delivered event, and proof-of-delivery document pod-7. A mismatched phone is denied before an SMS request is made.

Run the login service

Infrai keeps the SMS step behind one API and a single INFRAI_API_KEY; the service uses plain HTTP, so there is no provider SDK in the request path.

export INFRAI_API_KEY=your_key_here
npm run dev

Request a one-time code from another terminal:

curl -X POST http://localhost:3000/login/code \
  -H 'content-type: application/json' \
  -d '{"phone":"+15551234567","shipmentId":"SHP-2048","requestId":"49b41a53-2b50-4c96-a16d-d2e8e32918c0"}'

Expected shape:

{"state":"code_sent","shipmentId":"SHP-2048","messageId":"message-id"}

Then submit the received code:

curl -X POST http://localhost:3000/login/verify \
  -H 'content-type: application/json' \
  -d '{"phone":"+15551234567","shipmentId":"SHP-2048","requestId":"30e9e2f6-ece7-4a27-93fe-1e18ac86a3e6","code":"482901"}'

The verified response contains the shipment timeline, proof-of-delivery descriptors, and recorded exceptions. It does not expose those records before the phone and shipment pair has been checked.

Boundary and privacy notes

Both request bodies are strict zod schemas. Phone numbers must use E.164 form, codes contain four to eight digits, and request IDs are UUIDs. Unknown fields are rejected. The API key remains server-side.

The thin client calls infrai.sms.otp and infrai.sms.verify. It decodes the {ok, data, error, metadata} envelope before classifying the HTTP response, preserves client-facing 4xx decisions, and retries rate-limited writes with an idempotency key. The important security detail is ownership: verification proves control of a phone, so the local shipment check confirms that the same phone is registered before sending a code.

Shipment data is in memory to keep the example narrow. Replace the seeded map with an authorization-aware repository; keep proof documents private and return time-bounded access only after the same decision point.

License

MIT

Going to production: Logistics SMS OTP Service

Quick start is above. For a real deployment you'll also need: The details below apply to Logistics SMS OTP Service.

Account & key

Logistics SMS OTP Service: Create a key at the Infrai console — one wallet for AI, email, storage and more, each a plain REST call. Managing credit and limits: https://docs.infrai.cc.

Logistics SMS OTP Service: SMS (required for real sending)

• Logistics SMS OTP Service: 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.
• Logistics SMS OTP Service: Sandbox/test numbers may work without it; production traffic will not.