Generate an API key

Generate an API key

The BizRnR API gives you programmatic access to conversations, contacts, and webhooks. Every API call needs an API key. Keys are scoped to your tenant and can be created, rotated, or revoked at any time.

Create your first key

1. Sign in to the dashboard.
2. Open Settings → API → Keys.
3. Click New API key.
4. Give the key a descriptive name — something like "Production server" or "Zapier integration". You'll thank yourself later.
5. Choose a scope:

• Read-only — can read conversations, contacts, and analytics. Cannot write.
• Read + write (default) — full access except for billing and tenant settings.
• Webhook — can only verify webhook signatures. Use this for incoming webhooks if you're paranoid about token leakage.

1. Click Generate. The full key is shown once on this screen — copy it immediately.

You'll see two values:

• Public key — pk_live_... — looks like an identifier; not secret on its own
• Secret key — sk_live_... — this is the one that authenticates calls; treat it like a password

The secret key is hashed in our database; we cannot recover it after this screen. If you lose it, you'll need to revoke the key and generate a new one — no reset path exists.

Use the key

Send the secret key as a Bearer token in the Authorization header:

curl https://api.bizrnr.com/v1/conversations \
  -H "Authorization: Bearer sk_live_your_secret_key_here"

Every endpoint accepts this format. If you're using the official SDK, set the key once at boot:

import { BizrnrClient } from '@bizrnr/api-client';

const client = new BizrnrClient({
  apiKey: process.env.BIZRNR_API_KEY!.trim(),
});

Always read the key from an environment variable — never hardcode it into your source. The .trim() call guards against trailing newlines that some hosting dashboards bake in.

Rotate keys regularly

Best practice is rotating keys every 90 days, or any time someone with access leaves the team. Rotation is zero-downtime:

1. Generate a new key.
2. Deploy the new key to your environment (most platforms hot-reload env vars; otherwise restart).
3. Confirm traffic is flowing on the new key (Settings → API → Keys shows last-used timestamp).
4. Revoke the old key.

The dashboard shows you per-key usage in the last 30 days, so you can confirm nothing is still calling the old key before you revoke.

Revoke a leaked key immediately

If a key leaks (committed to GitHub, posted to Slack, sent in plain email), revoke it the moment you notice:

1. Settings → API → Keys → find the key by name → click Revoke.
2. Generate a replacement.
3. Audit the dashboard's API logs for the last 24 hours — anything you didn't recognize should be reported to security@bizrnr.com.

Revocation is immediate. Any in-flight requests with the revoked key get a 401 unauthorized response within seconds.

If you accidentally committed a key to a public Git repo, also rotate the key — *removing the commit doesn't unleak it.* GitHub's secret-scanning will tell us within minutes and we'll revoke it for you, but rotating yourself is faster.

Per-tier limits

| Tier | Active keys | Requests/min | |---|---|---| | AI Receptionist | Not included by default | Not included by default | | Enterprise/API-enabled | Contracted | Contracted |

Hitting the rate limit returns 429 too many requests with a Retry-After header. The SDK respects Retry-After automatically and exponentially backs off; if you're rolling your own client, do the same.

What's next

Once you have a key, the Authentication + rate limits article covers how to handle 401/429 responses gracefully, set up webhook signing, and use idempotency keys on writes.