# WhatsApp API for software houses — ship the channel inside your client's project

> URL: https://wame.api.br/en/api-whatsapp-para-software-house
> Software houses: stop rebuilding the WhatsApp integration on every project. One SDK, three official Meta channels and one webhook — plus a monthly fee of your own on top of each client. Partner Program from 20 instances, no lock-in.

## For teams that build custom software

WAME is your software house's messaging layer. One SDK, three official Meta channels and one webhook — the same code in every project you ship. Plus a monthly fee of your own on top of each client.

You write the integration once. It serves every project you ship from here on.

## What you rebuild on every project

The work was never sending a message. It is keeping alive an integration you already delivered and no longer bill for.

**Rebuilding it on every project:**

- Creating a Meta for Developers app per client
- Business verification under the client's company — and the wait
- One webhook parser per channel, three in total
- Unbilled support every time Meta changes the API
- A 40-hour estimate that turns into 200
- Project delivered, revenue over

**With WAME underneath:**

- No Meta app — the infrastructure is ours
- Nothing under your client's name, no waiting
- One parser for all three channels
- API changes are our problem, not yours
- A predictable integration, from the first project to the tenth
- Project delivered, subscription starting

We are a Meta Business Partner. The official infrastructure is already built and maintained on our side — your team consumes it and ships.

## What changes in your next proposal

- **1 SDK** — Write it once, reuse it in every project: The module you build for today's client drops into the next one unchanged. The integration stops being a line item and becomes an in-house library.
- **1 webhook** — One handler serves all three channels: WhatsApp, Instagram and Messenger arrive in the same envelope. A single field names the channel. The client who asks for Instagram tomorrow is not a new project.
- **0 Meta apps** — The red tape is neither yours nor your client's: No approved app, no business verification under your client's name, no becoming a Tech Provider. The step that stalls delivery for weeks — the one nobody can estimate — disappears.

## Three channels. The same webhook

You write the handler once. It serves all three — and the next client too.

- WhatsApp, Instagram and Messenger in the same payload format
- Official and unofficial with the same SDK and the same webhook
- The choice is per instance — migrate without rewriting anything
- SDKs in PHP and JavaScript

- **WhatsApp** — Official Cloud API
- **Instagram** — Official Direct API
- **Messenger** — Official Send API

The incoming event — only the provider field changes:

```json
{
  "object": "wame",
  // whatsapp | instagram | messenger
  "provider": "instagram",
  "entry": [{
    "id": "<instance-id>",
    "changes": [{
      "field": "messages",
      "value": {
        "messages": [{
          "from": "5511999990000",
          "type": "text",
          "text": { "body": "Hi! 👋" }
        }]
      }
    }]
  }]
}
```

Your side of it — one module for all three:

```js
// One module. Every project you deliver reuses it.
export function wameWebhook(req, res) {
  const { provider, entry } = req.body;
  const msg = entry[0].changes[0].value.messages?.[0];
  if (!msg) return res.sendStatus(200);

  onIncomingMessage({
    channel: provider,   // whatsapp | instagram | messenger
    from: msg.from,
    text: msg.text?.body,
  });

  res.sendStatus(200);
}
```

## How it fits the system you deliver

The end client never sees WAME. They see WhatsApp working inside the system you built.

1. **You create the instance through the API** — Create, activate, deactivate and delete are your calls. Provisioning happens inside your own onboarding — nobody opens a dashboard of ours.
2. **Your client connects their account** — Secure login through Meta itself on the official API, or a QR code on the unofficial one. They pick WhatsApp, Instagram and/or Messenger.
3. **Everything lands on your webhook** — All three channels in the same envelope, at the URL you configured. WhatsApp becomes a feature of your system — not a separate project.

Fully API-managed. The client lifecycle lives in your billing, not in our dashboard — so trials, suspensions and reactivations are your call.

## The choice is per client, not per vendor

You do not need two vendors to serve two sizes of client. Same platform, same SDK, same webhook.

### Official API (Meta)

For the client who needs a contract, scale and the number under their own name.

- No risk of the number being blocked
- Coexistence: your client keeps replying from the phone
- Instagram and Messenger on the same instance

### Unofficial API (QR code)

For the small client who wants to start today with no per-conversation cost.

- Connects by scanning a QR code, no approval
- No per-conversation charge from Meta
- Buttons, lists, polls, groups and Pix in the message

Moving a client from one to the other does not rewrite your code: the instance changes, the handler stays the same.

## From fixed scope to recurring revenue

Volume pricing, a single consolidated monthly invoice and Enterprise permissions on every instance. From 20 instances, no lock-in.

| instances | Price per instance/month |
|---|---|
| 20–99 | BRL 28.00 |
| 100–299 | BRL 24.00 |
| 300–799 | BRL 20.00 |
| 800+ | on request |

Platform cost only. On official instances, conversations are billed separately by Meta, straight to your client's account.

## Before you ask

**What if the client wants to take their number and leave?**
The number belongs to the client, and that does not change. On the official API the account is created in their own Business Manager, so they can leave whenever they want — including leaving you. It is an awkward thing to say on a sales page, but it is what separates a partner from a hostage: whoever stays, stays by choice.

**Can I run it under the client's company or does it have to be mine?**
Either works. On the official API the WhatsApp account sits in the client's Business Manager while the instance sits in your partner account — they own the number, you own the operation. If you would rather keep everything under your own name, that works too.

**Who supports the end client when something breaks?**
You do — it is your brand in front. But the people supporting you are the ones who build the platform, directly, not a tier-1 agent reading a script. Channel failures, odd webhook behaviour and payload questions reach whoever touches the code.

**Can the client be unaware that WAME exists?**
Yes. Everything is managed through the API, inside your onboarding and your billing. The client sees WhatsApp working in the system you delivered; there is no dashboard of ours in front of them.

**I only have 3 clients asking for WhatsApp today. Is it worth it?**
Not for the partner program yet — that starts at 20 instances. But you can use the platform per client right away and join the program once the volume is there. The code does not change; the invoice does.

**What if I already have an unofficial integration running?**
No need to throw it away. Official and unofficial share the same SDK and the same webhook format, and the choice is per instance. Put new clients on the official API and migrate the older ones at your own pace, without rewriting the handler.

## Ship WhatsApp inside your client's project without becoming an integration company

One SDK, three channels, one webhook — and a revenue line that does not end when the project does.

Since 2017 in the messaging API market · 50k+ instances created · 99.9% uptime · Meta official Business Partner

Got your own product? See the CRM and SaaS page: https://wame.api.br/en/whatsapp-api-para-crm-e-saas · About the official API: https://wame.api.br/en/oficial · All events: https://wame.api.br/en/docs/webhooks · API reference: https://wame.api.br/en/docs/api · Public uptime: https://wame.api.br/status