Connect WhatsApp to your own app or software

Two directions: send and listen

Every WhatsApp integration does two things. Your software sends messages out: an order confirmation, a reminder, a reply typed in your own screen. And your software listens: it hears when a customer writes, when a message is delivered or read, when a form is submitted. The first direction uses a REST API; the second uses webhooks, which are HTTP calls made to an address on your server.

You could build both directly on Meta's Cloud API. Many teams prefer to go through a platform like WaKite, because the number, the templates, the inbox, the opt-outs and the team already live there. Your code then talks to one API, and anything it sends also appears in the shared inbox, so your support team sees the full history.

Getting access: one key per workspace

In WaKite, API access belongs to a workspace. You create an API key in the developer settings, give it a name, and choose what it may do, for example send messages, read messages, read or write contacts, or read templates. A key can have an expiry date and can be limited to your server's IP addresses, and each key has its own rate limit.

Treat the key like a password. Keep it on your server, in an environment variable or a secrets store, and never put it in a mobile app, a browser script or a public repository. Create a separate key for each system that calls the API, so you can switch one off without breaking the others.

• Name each key after the system that uses it
• Give it only the permissions it needs
• Restrict it to your server IPs where you can
• Rotate it when someone leaves the project

Sending messages from your app

Sending is a single request, in the style of POST /messages, with the recipient and the content. What content you may send depends on the 24-hour customer service window. If the customer wrote to you in the last 24 hours, you can send ordinary text, files and buttons. If not, you must send an approved template, filling its variables with values such as the name or the order number.

Most app-triggered messages fall outside the window, so plan your templates first. Write one for each event, submit it for approval, and read the list of approved templates through the API before you send. Keep the message id that comes back: you will use it to match delivery and read updates later, and to find the message if a customer asks about it.

Receiving events with signed webhooks

Webhooks tell your system what happened. You add an endpoint URL in WaKite, choose the events you want, and receive a JSON body for each one: a message received or sent, a delivery or read status, a new contact, a chat assigned or resolved, a reply target missed, a template approved or rejected, a form submitted, a pipeline card moved, a campaign finished.

Each delivery is signed. The request carries a timestamp and an HMAC-SHA256 signature made with your webhook secret, so your server can check it really came from WaKite and was not replayed later. Answer quickly with a 2xx status and do the heavy work in the background. Failed deliveries are retried several times, so use the event id to ignore a delivery you have already handled.

• Verify the signature before you trust the body
• Reject old timestamps to stop replays
• Return 2xx fast; queue the real work
• Store event ids so retries are harmless

Typical integrations

Order and delivery updates are the most common start: your store or ERP sends a utility template when an order is placed, packed, shipped and delivered. Appointment reminders work the same way. One-time codes for sign-in or payment confirmation use Meta's authentication template category, which exists for exactly that purpose and has its own rules on wording.

CRM sync is the other big one. When a contact is created in WaKite, a webhook can create or update the record in your CRM; when your CRM learns something new, the API can update the contact. Pipeline events let a sales system follow a lead from first chat to won or lost. Start with one event in one direction, then add more.

Building with an AI coding assistant

Many teams now write integrations with an AI coding assistant. WaKite offers a ready guide file in the developer area that describes the API, the webhooks, the event fields, the error codes and example requests in one document. Give that file to your assistant as context, together with a short description of what your app should do, and it has the details it needs.

Review what it produces as you would review a new developer's code. Check that the API key is read from configuration and not written into the code, that the webhook signature is verified, and that template sends handle errors such as a closed window or an opted-out contact. Then test with your own number before any customer sees a message.

Step by step

1. 1
   Create an API key

   In the developer settings, create a key for your system with only the permissions it needs.

2. 2
   Prepare templates

   Write and submit a template for each event your app will announce, and wait for approval.

3. 3
   Send a test message

   Call the messages endpoint from your server with a template and your own number as the recipient.

4. 4
   Add a webhook endpoint

   Register your URL, pick the events, and verify the signature on every delivery.

5. 5
   Go live gradually

   Switch on one event for real customers, watch statuses and errors, then add the next.

Questions