Web Rabbit Media — Payments, SMS & Custom Software

The Web Rabbit API uses bearer token authentication. Every request must include your secret key in the Authorization header.

API keys

Manage keys from Developer → API Keys. Keys are prefixed by mode (wr_test_... or wr_live_...) and scoped by access (read or read + write, chosen at creation). Test keys work any time; live keys only work once your business is approved. Write scope is required for /v1/checkout/session.

!Keep secrets server-side

Never embed a secret key in a mobile app, browser bundle, or public repo. Anyone with your key can create charges on your behalf.

iOne base URL — mode inferred from the key

There is no separate host to call. wr_test_... keys are answered by Web Rabbit's built-in simulator — no provider call, no prompt to a handset, no debit, amounts capped at GHS 10 — and wr_live_... keys hit production rails. Both go to https://api.webrabbitmedia.com; test and live data are fully isolated. See Test data.

Sending the key

Authorization header

Authorization: Bearer wr_test_1a2b3c4d5e6f...

shell

curl https://api.webrabbitmedia.com/v1/me \
  -H "Authorization: Bearer wr_test_1a2b3c4d5e6f..."

Requests without a valid key return 401 Unauthorized.

Identify your app

Send two extra headers with every API request so Web Rabbit knows which site and product your key is powering. This is how we attribute traffic, spot key leaks, and review integrations.

Attribution headers

HTTP-Referer: https://your-app-site.com
X-Webrabbitmedia-Title: Your App Name

shell

curl https://api.webrabbitmedia.com/v1/collect/momo \
  -H "Authorization: Bearer wr_live_..." \
  -H "Content-Type: application/json" \
  -H "HTTP-Referer: https://your-app-site.com" \
  -H "X-Webrabbitmedia-Title: Your App Name" \
  -d '{"amount":10,"phone":"0248000000","network":"mtn"}'

HTTP-Referer — the public URL of the site or app using the key. If you omit it we fall back to the standard Referer or Origin header when present.
X-Webrabbitmedia-Title — the human-readable name of your product, shown to our review team.

Every distinct site + app name appears under Developer → Applications in your dashboard, with request counts and review status. Requests that arrive without attribution still succeed, but the response carries a x-wr-attribution-warning header.

iAlready integrated before these headers existed?

Nothing breaks. Existing keys keep working exactly as before — there is no cutover date and undeclared traffic is never blocked. It is simply grouped in your dashboard as Not declared with a request count, so you can see which integration still needs the headers. Add them when you next deploy. Server-to-server code sends no browser referer, so set HTTP-Referer explicitly to your site rather than relying on the fallback.

!Declarations are reviewed by humans

Attribution must be truthful. If a review finds the declared site or app name is false or does not match the live integration, the key — and in serious cases the account — can be suspended. If you move to a new domain or rebrand, tell us at support@webrabbitmedia.com before you switch so we can update the record. Live requests from a host we have blocked return 403 domain_blocked; test mode is never blocked.

Scopes — read vs read + write

Each key is granted one of two scopes at creation, controlled by the Enable write access checkbox in the dashboard:

read (checkbox off) — can retrieve transactions and account info.
read + write (checkbox on) — everything read can do, plus create collections and checkout sessions.

Scope required per endpoint:

Endpoint	Required scope
`GET /v1/me`	read
`GET /v1/transactions`	read
`GET /v1/transactions/{id}`	read
`POST /v1/collect/momo`	write
`POST /v1/checkout/session`	write

A request that requires write but is made with a read-only key returns 403 Forbidden with this body:

403 insufficient_scope

{
  "error": "insufficient_scope",
  "required": "write",
  "granted": "read"
}

The scope is baked into the key at creation and cannot be changed later — revoke and create a new key to change access.

Preflight — check mode & approval

Before you charge a real customer, call GET /v1/me to confirm the key's mode, scopes, and that the business is approved for live rails. See Me.

Legacy keys without a prefix

Keys issued before prefixed-key rollout have no wr_test_ / wr_live_ prefix and continue to authenticate as-is — no rotation required. If you'd like a prefixed replacement, create a new key from Developer → API Keys and revoke the old one when you cut over.

Rotating keys

If a key is exposed, revoke it from the dashboard and create a new one. Rotation is instant — the revoked key stops working immediately.

Keys created by teammates

A key only works while the person who created it is still the business owner or an owner, admin or editor on the team. Removing a teammate, or lowering them to viewer, disables every key they created straight away (requests return 401 API key revoked). For long-running integrations, have the business owner create the key.

Authentication