API Security Best Practices: Domain Binding & Key Rotation

API keys are the keys to the kingdom — anyone with your key can spend your monthly quota, hit your rate limits, and (if you have enterprise endpoints enabled) make calls that cost real money. This guide walks through the security features the Satta Matka API provides and the practices you should follow on your end.

The threat model

Before any security feature makes sense, you need to know what you are defending against. The realistic threats to a matka API key are:

1. Frontend exposure — your key ends up in client-side JavaScript, anyone can read it from devtools.
2. Repo leakage — your key gets committed to a public GitHub repo.
3. Server compromise — an attacker gets RCE on your server and reads .env.
4. Insider threat — a developer or contractor with key access leaves and takes the key with them.
5. Quota theft — a competitor scrapes your key from your site and burns your quota.
6. DDoS amplification — a leaked key is used to fire thousands of requests per second at the API to either exhaust your quota or to DDoS your own backend via webhook floods.

The good news: every one of these is mitigated by features the API already provides.

Defense 1: Never expose the key in the browser

The single most important rule: your API key should never appear in client-side code. Not in a <script> tag, not in a fetch call, not in an environment variable that gets inlined into the bundle.

The correct pattern is to proxy all API calls through your own server. Your server holds the key in an environment variable, adds the auth header, and forwards the response.

// app/api/results/route.ts — Next.js route handler
export async function GET() {
  const res = await fetch('https://sattamatkaapi.live/api/results/live', {
    headers: { Authorization: `Bearer ${process.env.MATKA_API_KEY}` }
  })
  return new Response(res.body, {
    headers: { 'Content-Type': 'application/json', 'Cache-Control': 's-maxage=30' }
  })
}

If you absolutely must call the API directly from the browser (e.g. a static site on GitHub Pages), use a key with strict domain binding (see below) — but treat this as a last resort.

Defense 2: Domain binding

Domain binding tells the API "this key is only allowed to be used from these specific origins". When a request comes in, the API checks the Origin header — if it doesn't match the allowed list, the request is rejected with 403 Origin not allowed.

Configure this in your dashboard: API Keys → Edit → Allowed Domains. Add your production domain(s):

• yourdomain.com
• www.yourdomain.com
• app.yourdomain.com

You can also configure it via the API:

curl -X PATCH https://sattamatkaapi.live/api/keys/{id} \
  -H "Authorization: Bearer $MATKA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "allowedOrigins": ["yourdomain.com", "www.yourdomain.com"]
  }'

Once set, requests from evil.com (or localhost if you forgot to add it) will be rejected. This single feature neutralizes the "stole the key from frontend JS" attack — even if someone reads your key, they cannot use it from their own domain.

Defense 3: IP allowlisting (for server-to-server calls)

For server-to-server calls (no browser, no Origin header), domain binding does not apply — the request has no origin. For these, use IP allowlisting:

curl -X PATCH https://sattamatkaapi.live/api/keys/{id} \
  -H "Authorization: Bearer $MATKA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "allowedIps": ["203.0.113.42", "203.0.113.43"]
  }'

Only requests from these IPs will be accepted. This is the right call for backend cron jobs, webhook receivers, and any non-browser client.

If your backend uses dynamic IPs (e.g. serverless functions on Vercel), do not use IP allowlisting — use a "trusted" key instead, which disables the origin check entirely. Trusted keys should ONLY be used on backends you control; never mark a browser key as trusted.

Defense 4: Key rotation

If you suspect a key has been compromised — leaked to a public repo, exfiltrated by a former employee, or just been in use too long — rotate it. Rotation generates a new key string and revokes the old one immediately.

curl -X POST https://sattamatkaapi.live/api/keys/{id}/rotate \
  -H "Authorization: Bearer $MATKA_API_KEY"

The response returns the new key:

{
  "ok": true,
  "key": "smk_live_newkey...",
  "keyPrefix": "smk_live_newk",
  "rotatedAt": "2026-08-14T12:00:00Z"
}

Update your environment variables, redeploy, and the old key is dead. Rotation preserves the key's settings (allowedOrigins, allowedIps, plan, quota) — only the secret changes.

Best practice: rotate quarterly

Even if you have no reason to suspect compromise, rotate keys every 90 days as a hygiene measure. This limits the blast radius of any leak you don't know about.

Automate the rotation:

// scripts/rotate-key.js
const KEY_AGE_DAYS = 90
const lastRotatedAt = new Date(process.env.KEY_ROTATED_AT)

if (Date.now() - lastRotatedAt.getTime() > KEY_AGE_DAYS * 86400000) {
  const newKey = await rotateKey(process.env.MATKA_KEY_ID)
  await updateEnvFile('MATKA_API_KEY', newKey.key)
  await updateEnvFile('KEY_ROTATED_AT', new Date().toISOString())
  await deploy()
  console.log('Key rotated successfully')
}

Run this as a quarterly cron job.

Defense 5: Use the right key for the right job

Don't use a single key for everything. Issue separate keys for:

• Production frontend — domain-bound, no IP allowlist, normal rate cap.
• Production backend — IP-allowlisted, no domain binding, possibly higher rate cap.
• Staging — separate key for staging so a leak in staging does not affect production.
• CI/CD — separate key with minimal scopes (e.g. read-only), rotated more frequently.
• Third-party integrations — if a contractor needs API access for a one-off analysis, issue a temporary key with a 7-day expiry.

Each key has its own quota counter and rate limit — if one key gets rate-limited, the others continue to work.

Defense 6: Set key expiry

For trial keys, contractor keys, and any temporary access, set an expiry date. The key automatically stops working after that date — you don't need to remember to revoke it.

curl -X POST https://sattamatkaapi.live/api/keys \
  -H "Authorization: Bearer $MATKA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "label": "Contractor — 7-day access",
    "expiresAt": "2026-08-21T00:00:00Z",
    "allowedOrigins": ["contractor-workspace.example.com"]
  }'

Defense 7: Monitor key usage

The dashboard shows per-key request counts and last-used timestamps. Review these weekly — if a key you thought was unused has 5000 requests yesterday, you have a problem.

You can also pull usage via API:

curl -H "Authorization: Bearer $MATKA_API_KEY" \
     https://sattamatkaapi.live/api/keys/{id}/usage

Returns daily request counts for the last 30 days, broken down by status code. Hook this into your alerting — if a key's daily usage spikes 5x above its 30-day average, fire an alert.

Defense 8: Revoke on suspicion

If you see unusual activity and you are not sure whether the key is compromised, revoke it. Revocation is instant and irreversible — the key stops working immediately.

curl -X POST https://sattamatkaapi.live/api/keys/{id}/revoke \
  -H "Authorization: Bearer $MATKA_API_KEY"

After revoking, issue a new key, update your environment, redeploy, and rotate any dependent keys (e.g. webhook secrets).

Checklist

• [ ] Key is never in client-side code (frontend calls your backend, backend calls the API).
• [ ] Domain binding is set for all frontend-facing keys.
• [ ] IP allowlist is set for all backend-only keys.
• [ ] Keys are rotated every 90 days.
• [ ] Separate keys for production, staging, CI, contractors.
• [ ] Temporary keys have expiry dates.
• [ ] Key usage is monitored weekly.
• [ ] Revocation + rotation procedure is documented.

If you can tick all of these, your API key security posture is in the top 1% of integrations. The remaining 99% of risk is on the API provider's side — and that is what we are here for.