WhatsApp Business API for Nigerian MSMEs: What Nobody Tells You Before You Start Building

Meta's WhatsApp Business Platform docs make the integration look like a weekend project: register a number, verify a business, send a message, receive a webhook. Building something a Nigerian MSME can actually depend on for daily orders is a longer story, and most of the hard parts are not in the API reference.

Business verification and template approval take longer than the roadmap allows

Meta Business verification for a Nigerian entity routinely takes longer than for equivalents in the US or UK, and message template approval — required for anything sent outside a customer-initiated 24-hour window — can bounce for reasons that are not always obvious from the rejection reason. Build the launch timeline assuming verification takes weeks, not days, and get templates submitted before any other part of the build is finished.

The 24-hour session window changes your entire architecture

Free-form messages are only allowed within 24 hours of the customer's last message. Outside that window, only pre-approved template messages can go out. This is not a minor detail — it dictates how order confirmations, delivery updates, and payment reminders have to be architected, because a naive implementation will silently fail to deliver messages the moment that window closes.

Meta's policy on AI-generated text is stricter than most teams assume

Meta's commerce policies restrict fully AI-generated conversational replies to end customers in several contexts. The safer, more durable pattern is to use an LLM for structured extraction — pulling intent, order details, and entities out of a free-form customer message into a validated schema — while customer-facing replies stay template-driven or human-authored. This also happens to produce more predictable, debuggable behavior than free-form generation.

Building for Nigerian network conditions

• Webhook delivery needs idempotency keys and deduplication — intermittent connectivity means Meta will retry, and a naive handler will double-process orders.
• Queue-based processing (not synchronous request handling) is not optional. A worker that blocks on a slow downstream call during a network hiccup will back up the entire message pipeline.
• Design for message delivery confirmation as a first-class state, not an afterthought — "sent" and "delivered" are different states, and MSME owners will ask why a customer never got their order confirmation when the honest answer is a delivery failure, not a bug.

What we would tell any team starting this today

Start the business verification and template approval process before writing a line of application code — it is the long pole. Build the worker/queue layer assuming failure is the normal case, not the exception. And design the conversation flow around the 24-hour window from day one, because retrofitting it later means rearchitecting the whole notification system.

Christian Chukwuka

Founder & AI Systems Engineer