· 4 min read
Wiring a confirmation call into a store is an afternoon of work. Getting it right so that it keeps working on a busy Friday, when the courier pickup is at four and the network is flaky, is a few decisions made up front. This is the list we hand to developers before they start.
The integration guide has the endpoint details. This post is about the shape.
Send the call request when the order is final, not when the cart is created
The call reads the order back to the customer. If the order can still change after the request goes out (a coupon applied late, a quantity edited), the customer hears the wrong order and says no. Send the request from the point in your flow where the order is what the courier will carry.
Make the request idempotent
Order webhooks fire twice. Workers retry. If the same order can produce two call requests, the customer gets two calls and confirms the same order twice, or worse, a duplicate is created on your side. Use the order number as the request's identity: the same order number is the same call request, no matter how many times it is sent.
Verify the webhook signature, every time
The result comes back to your webhook signed. Verify the signature before you touch the payload. A webhook endpoint that accepts anything is an endpoint that will one day mark an order confirmed because someone guessed the URL. Read the signing secret once at deploy time, keep it out of logs, and rotate it if it ever leaks.
Treat "confirmed" as the only automatic path
The result carries the outcome and, for anything but a clean confirmation, a reason. Only a confirmed result should move an order to "ready to ship" on its own. Cancelled, changed, wrong number, no answer and abusive all belong in a hold queue for a person. Build the hold queue first; it is where the value is.
Keep the address the customer said beside the one you sent
The result includes the address as you sent it, plus the thana and district the customer gave, plus a pre-joined label line. Store all of it. The original address is what the customer typed; the spoken thana and district are what the courier needs; the label line is what you print. Do not overwrite the original, and do not try to merge them into one field.
Expect the result late, and reconcile
Most results arrive within minutes. Some take longer: the customer did not answer and the retries are spaced out over hours. Your webhook receiver should be happy to hear about an order it last saw yesterday. Also run a sweep, once an hour or so, that asks for the status of any order still waiting; a webhook can be missed even with retries, and the sweep closes the gap.
Watch the balance
Minutes are prepaid. The result payload tells you how many seconds remain; when it drops below a day's worth of calls, alert someone. A shop that runs out of balance at three in the afternoon ships unconfirmed orders that evening.
Test on your own phone first
Every account starts with a staging assistant that calls the number you give it. Send it a real order shape with your own phone number, listen to the call, read the webhook payload, and only then point the integration at customers. It takes ten minutes and it catches most surprises.
Sworborno's API is one endpoint to request a call and one webhook to receive the result, with signed payloads and retries built in. The docs walk through both; sign up and the staging assistant is ready when you log in.