What the WhatsApp Business API actually changes for an Algerian shop

At nine at night a customer asks where his order is. The answer is already known: it left the shop on Tuesday, it is at the agency in Djelfa, and delivery is attempted tomorrow. Someone still has to open the chat, find the order, and type that answer by hand — the fortieth time the same sentence has been typed that week.

The WhatsApp Business API does not make that customer less impatient. It makes the answer something a system sends, and it makes the incoming message something a system can store.

What the API is, without the marketing

The WhatsApp Business app is one phone with a human attached. A number registered on Meta's platform instead behaves like an endpoint: incoming messages arrive at your server as webhooks, replies leave as API calls, and both directions are programmable. Meta hosts this as the Cloud API; the older on-premise version is being retired, so the hosted route is the one to plan around.

The practical difference is not "automation". It is that the conversation can become an input to something else — an order, a customer record, a delivery status — instead of ending in a person's memory.

The three setups that exist in practice

Every option below is real and none of them is wrong. What changes is who answers and who maintains the thing.

	WhatsApp Business app	Hosted platform	Cloud API with your own backend
Who answers	one phone, one person at a time	several agents in a shared inbox	your system, with people for exceptions
First cost	none	a monthly subscription	a build, plus Meta's message fees
What you maintain	nothing	nothing technical	a server, a token, and the code
Shared team inbox	no	yes	only if you build it
Data lives	on the phone	at the vendor	in your database
Fits when	under twenty orders a day	you want a team inbox this month	the order data must live in your system

The middle option is usually the right one for a shop that has staff but no developer. The third is right when the point is not the chat at all but the order record behind it — and it is the only one where the conversation and the order can share a single source of truth without a nightly export.

The number is the first real decision

A number cannot be on the API and in the WhatsApp app at the same time. If the shop's business number already has a WhatsApp account, migrating it means deleting that account first, which takes the chat history with it. The alternatives are a second SIM used only for the API, or a migration done deliberately with the customer-facing number, announced in advance.

This is worth deciding before anything is configured, because it changes what customers see. A shop that suddenly answers from a new number looks like a shop that changed owners.

Templates, and the window you cannot cross

Free-form replies are only allowed inside the service window that opens when the customer messages you. Outside it, you send a template that Meta has approved in advance. Templates are reviewed, and vague marketing copy tends to come back rejected while a plain transactional message usually passes.

The consequence is practical: the messages worth writing are the four the shop sends every day anyway.

1. Order received — order number, items, total, delivery price.
2. Dispatched — courier, tracking if the courier provides one, expected day.
3. Out for delivery, or at the agency for collection.
4. Delivered, or refused, with what happens next.

Write those four before writing any code. If they cannot be made accurate, the order record behind them is not ready either, and the API will only make the inaccuracy faster.

Connect it to an order, not to a chat

The common failure is an automation bolted directly onto a phone number. A customer writes "where is my order" and receives a cheerful reply that contains no information, because there is nothing behind the number except an auto-responder.

The API should read from the order record and write to it. A confirmation template is only worth sending if it is generated from a row that a packer can also see. A delivery notice is only worth sending if it changes the order's status when it is sent. Where the shop has no order record yet, the order record comes first and the API second — the reverse order produces a very fast way to send wrong information.

What to automate, in order

1. The acknowledgement. Customer messages, an order is created, the details go back for confirmation. This removes the "did they see my message" anxiety that produces three follow-up messages per order.
2. The dispatch notice. It answers "where is my order" before the question is asked, which is why it is the second thing worth automating.
3. The status answer. When the question does arrive, the reply is read from the record rather than typed.
4. The refusal follow-up. A refused parcel gets a template with the return terms, instead of a debate.
5. Broadcasts, last, and only to customers who asked for them.

Broadcasts are the part everyone wants first and the part that damages a number fastest. A list that receives two offers a week and never a useful update is a list that mutes the shop.

What it costs, and what it does not fix

Meta bills business-initiated messages, and the rate depends on the message category and the country. That price list changes; read the current one rather than a blog post, including this one. Your own costs are the server, which is small, and the time to build and maintain the integration, which is not.

What the API does not do is improve a courier, fix a wrong address, or make a customer answer the phone. It also does not stop people from messaging the owner's personal number, which is why the business number needs to be the one on every post, every parcel and every invoice.

Where this advice stops

If the shop takes fewer than twenty orders a day and one person handles them, the free Business app with labels and saved replies is enough, and it will stay enough for a while. If orders arrive through Instagram or Facebook Marketplace rather than WhatsApp, this is the wrong integration — those are different APIs with different rules.

If nobody can maintain a server, do not start with the Cloud API; use a hosted platform until the volume justifies something else. And if business verification is blocked by a document problem, fix the document. No amount of code gets past a rejected commercial register.

We build the order record and the integration behind it, and we will say when a hosted inbox is the better buy for the next year.