Sending alerts

When your system has something to say rather than something to ask. Order shipped. Build failed. Payment bounced.

An alert is a request with nothing to decide, so it has its own endpoint and takes no options. The message arrives from Jabee's number, with no buttons on it, on the phone of somebody who has verified it with us.

curl -X POST https://api.jabee.ai/api/v1/alerts \
  -H "Authorization: Bearer $JABEE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Nightly build failed",
    "body": "main @ 4f2a9c. Three tests red in billing.",
    "url": "https://ci.example/runs/8821",
    "external_id": "build-8821"
  }'

One option rather than none, because every request carries at least one button and a single Skip reads as "seen". If you want a record of who saw it, that tap is it, with the name and the time on the request. If you do not care, ignore the callback.

Who can be sent to

One phone per business, and it is your own. The account owner's number by default — nothing to set up — or a different handset, an ops phone or a shared on-call one, which you point alerts at in the dashboard, under Where alerts go. Either way it is verified the same way: that phone sends one message to the Jabee number, carrying a code from the dashboard. There is no recipient field on the API and nothing to address.

To reach several people, connect your own WhatsApp number and send from there. That is not a restriction we would rather not have — alerts here go out on a number shared by every business using Jabee, and the volume you send spends a sending reputation everybody else depends on. On your own number it is your relationship and your reputation, and you can send to as many of your people as you like.

Your customers cannot be reached this way at all, and that is on purpose. A shared number messaging people who never asked for it is what gets numbers banned.

Whoever holds the phone can end it at any time: reply STOP and nothing more goes to that handset until the account owner switches it back on, with one button in the dashboard. Approvals are unaffected: a request that asks a question still goes out. Alerts keep arriving by email meanwhile. And if three in a row go unanswered we stop sending there by ourselves and email the owner — one message from that phone starts it again, and so does the same button.

The dashboard says which of those you are in, on the Alerts screen: the number alerts are going to, or that they are going to the owner's phone, or that they are paused and why.

Why there is no number to set up

The usual route to a WhatsApp notification is: get a Meta developer account, get a WhatsApp Business Account, register a number, write a message template, submit it, wait for Meta to approve it, then send. That is days, and the template has to be re-approved every time the wording changes.

None of that applies here, because the number and the template are ours and already approved. The cost is the one in the next section.

Connecting your own number and writing your own templates instead? Check the draft before you submit it. Rejection is the usual first week of that route.

What that costs you

200 new requests per business in any 24 hours, and 60 API calls a minute per key. A repeated external_id does not count against the daily figure, so retries are free.

And the quality rule: three notifications in a row that a handset never answers and we stop sending to it, with an email to the account owner saying so. Email keeps working. Sending any message to our number starts WhatsApp again. We do this because one number's standing with Meta is shared by everybody on it.

If your volume is genuinely higher than 200 a day, connect your own number instead. That is what it is for.

Hearing back

Same as approvals: a signed webhook, or poll by id. Both are documented on the approvals page, and the two share one endpoint, one key and one webhook address.

Questions