Authentication
Rapiwa uses two kinds of credentials. Almost every call uses the Device Key.
Device Key (Bearer) — the public API
Every messaging, session, verify, and group endpoint authenticates with an HTTP Bearer token whose value is the Device Key:
Authorization: Bearer <deviceKey>
- A Device Key identifies exactly one linked WhatsApp device (
WhatsAppSession). - There is no separate API-key header for these endpoints — the Device Key is the token.
- Find or regenerate it in the dashboard under the device's settings.
curl https://app.rapiwa.com/api/info \
-H "Authorization: Bearer YOUR_DEVICE_KEY"
If the key is missing or wrong you get 401 UNAUTHORIZED:
{ "success": false, "error": { "code": "UNAUTHORIZED", "message": "Invalid Device Key" } }
Validate a key
Call GET /api/verify-device-key to check a Device Key and read back its session status.
Tenant API Key (apikey header)
One endpoint — GET /api/devices/by-api-key — lists all of a tenant's devices and authenticates with the account-level API key instead of a Device Key. It goes in a custom header (not Bearer):
apikey: <tenantApiKey>
Use this for integrations (e.g. a bot builder) that need to enumerate a customer's devices and then call the per-device endpoints with each device's own key.
Keep credentials secret
- Treat the Device Key and tenant API key like passwords — server-side only. Never ship them in browser or mobile client code.
- Rotate a Device Key from the dashboard if it leaks; the old key stops working immediately.
- All traffic must be over HTTPS.
Transport & format
| Rule | Value |
|---|---|
| Base URL | https://app.rapiwa.com |
| Path prefix | /api/... (messaging sends also answer without /api) |
| Method | POST for actions, GET for reads |
| Content-Type | application/json on every POST |
| Phone format | Any format accepted — non-digits are stripped, @s.whatsapp.net appended |
| Group id | A JID like 12345@g.us |