Sandbox vs Production API Keys: Scopes, IP Allowlists and Go-Live

Key takeaways

• The environment is resolved server-side from the key. sk_test_ means sandbox, sk_live_ means production. You do not pass an environment flag, so you cannot send a sandbox request "to production" by accident, but you can ship the wrong key.
• Sandbox calls are metered and logged but never debit your wallet. Production calls debit the fulfilment wallet once a priced verification completes successfully.
• Sandbox has a lifetime call quota. Going over it returns a 429, not a silent failure. The quota size is not published in the docs, so read it from your dashboard instead of hardcoding an assumption.
• Production keys need a KYC-approved organization and a per-product production application. Sandbox success does not guarantee approval.
• Give each key only the scopes it needs, name it after the service that uses it, and keep one key per service per environment.
• Per-key IP allowlisting restricts where a key can be used from. It supports an IP/CIDR list and does not replace secret hygiene.
• The raw key is shown exactly once at creation or rotation. Rotating invalidates the old secret immediately, so for zero downtime create a second key, deploy it, then revoke the first.
• Keep keys in a secret manager or environment secrets, never in source control, browser code or mobile binaries.

How does StampMitra decide whether a request is sandbox or production?

Every protected endpoint under /v1/* expects the key in either Authorization: Bearer <key> or an x-api-key header. The authentication reference states that keys are environment-scoped: SANDBOX keys start with sk_test_ and PRODUCTION keys start with sk_live_. The server reads the key, looks up which environment it belongs to, and runs the request there. There is no environment=production query parameter and no separate hostname to remember. The base URL used in the quickstart is https://api-b2b.stampmitra.in for both.

Why that design is useful

Because the environment travels with the credential, the safest way to switch environments is to switch the credential. Your code path does not branch on a mode flag, so the sandbox integration you tested is byte-for-byte the same request you will run live. The quickstart makes the same point: you verify a PAN in sandbox using the same request shape production uses.

The flip side is that the key is the only thing standing between a test and a real, billed call. If a sk_live_ key sits in a developer's local .env file, every experiment on that laptop is a production call. Treat the prefix as a safety label and check it in code, which the testing section below shows how to do.

What "resolved on the server" does not cover

The docs do not say that the platform inspects request bodies for test values. Sandbox runs against sandbox data, and the developer terms warn that sandbox data, responses and simulations may not represent actual production results, that sandbox limits do not equal production limits, and that sandbox functionality may be reset or modified. Plan on re-validating your response handling when you first go live rather than assuming a 1:1 match.

Header choice

Both headers are equivalent. Pick one per codebase. Use Authorization: Bearer if you also run an API gateway or proxy that already understands bearer tokens, because many log scrubbers redact that header by default. If you use x-api-key, add it to your logging redaction list explicitly.

Sandbox vs production keys at a glance

The table below pulls together what the platform pages state. Rows marked "not documented" are deliberate: they are places where this guide will not guess.

Two practical consequences fall out of this table. First, there is no shortcut to production by volume: a high-traffic sandbox integration is still a sandbox integration. Second, the failure modes differ, so your error handling should differ too. In sandbox you most often meet a quota 429. In production you meet a 402 when the wallet runs low. The errors and handling guide covers both in detail.

What does the sandbox quota do, and what is the 429?

StampMitra's home page lists two sandbox guarantees side by side. Sandbox calls "never debit your wallet," and sandbox carries "a lifetime sandbox call quota." The stated purpose is that sandbox proves your integration works; going over the quota returns "a clear 429, never a silent failure." The support FAQ repeats that a 429 means you hit a rate limit or your lifetime sandbox quota.

What the repository does not tell you

No numeric quota appears in the product data or the docs, so this guide does not quote one. The pricing page describes sandbox as unlimited test-mode calls, while the home page and support FAQ describe a lifetime quota. Those two statements read differently, so before you size a load test, check your own dashboard and ask support which applies to your account. Do not treat sandbox as a place to run production-scale tests either way: the acceptable use policy lists sandbox abuse as a prohibited use.

Telling the two 429s apart

A 429 can have two causes, and they need different responses.

• Per-endpoint rate limit: the documented error example reads "Rate limit exceeded: 60 requests per 60 seconds for this endpoint." This is a time-window limit. Back off and retry with jitter.
• Lifetime sandbox quota: this is a cumulative cap. Retrying will not help, because the cap does not refill with time. You need to stop spending calls, move to production, or contact support.

The documented error envelope is the same for every error: { "error": { "code", "message", "requestId" } }. The quota-specific message text is not documented, so branch on the message only defensively and log the requestId. The rate-limit example uses code TOO_MANY_REQUESTS.

{
  "error": {
    "code": "TOO_MANY_REQUESTS",
    "message": "Rate limit exceeded: 60 requests per 60 seconds for this endpoint.",
    "requestId": "a1b2c3d4-e5f6-4a1b-8c2d-9f0e1a2b3c4d"
  }
}

Spend the quota deliberately

Treat the sandbox quota as a budget. Cache verification results in your test suite, use fixtures for unit tests so only a handful of integration tests hit the network, and do not put sandbox calls inside a retry loop that fires on every 4xx. A test that loops on a 400 validation error will burn quota to prove nothing, since the PAN format is validated up front and fails fast.

How do you create a key with least-privilege scopes?

In the dashboard's API Keys page the create form asks for three things: a key name, an environment (Sandbox sk_test_ or Production sk_live_), and scopes. The form says to leave all scopes unchecked to get the default scopes for the environment, and the product data does not spell out what that default set contains. For anything beyond a first experiment, tick scopes explicitly so you know exactly what a leaked key could do.

The scopes the form offers

The scope names below come from the endpoint definitions and match what the create form lists.

Other e-Stamp endpoints use scopes such as estamp.read and estamp.duty.calculate, which are documented per endpoint on the e-Stamp docs pages but are not in the dashboard checkbox list shown today. If your integration needs them, confirm availability with support.

A decision rule for splitting keys

Create one key per deployable service and per environment, then give each the smallest set that service calls. A KYC onboarding worker that only verifies PAN and GSTIN needs verification.pan.read and verification.gstin.read. It does not need orders.create. A separate order service that books stamp paper needs services.read, orders.create, orders.read, payments.write, payments.read and documents.read, and nothing from the verification family. If the KYC worker's key leaks, the attacker cannot create orders.

What a missing scope looks like

A valid key without the right scope is rejected with a 403: FORBIDDEN, "API key is valid but lacks the required scope for this endpoint." That is a configuration bug, not an outage. Fix it by issuing a new key with the right scopes. The docs do not describe editing the scopes of an existing key, so plan on creating a replacement and revoking the old one.

What is a per-key IP allowlist, and when do you need one?

StampMitra's home page describes it plainly: restrict any key to an IP or CIDR list, and sensitive scopes like PAN and RC default to requiring one. The auth reference adds that sensitive scopes can additionally be restricted to an IP allowlist. The practical effect is that even if a key leaks, a request from an address outside your list is not meant to be accepted.

Why PAN and RC are called sensitive

Verification of PAN and vehicle registration returns personal data: registered names, father's name, owner details. A key with those scopes is worth stealing, so the platform makes the allowlist the default expectation for them. If you intend to use verification.pan.read or verification.rc.read, plan your egress addressing before go-live.

Designing an allowlist that survives infrastructure changes

An allowlist only works if the source address is stable. Serverless functions and autoscaled containers on shared pools often egress from changing addresses, so a list of individual IPs will break. A common pattern is to route outbound calls to StampMitra through a NAT gateway or a small egress proxy with a fixed address, then allowlist that one address or its CIDR. The API security policy puts the maintenance duty on you: keep authorized IPs accurate and update the list when infrastructure changes, and remember that allowlisting does not replace credential security.

What the docs do not say

Three details are not documented in the repository, so confirm them with StampMitra support before depending on them:

1. How an allowlist is attached to a key. The dashboard create form exposes name, environment and scopes only.
2. What response a blocked request receives. Do not assume it is a 403 with a specific code.
3. Eligibility. The pricing page lists per-key IP allowlisting under the Developer Suite tier, and the API security policy says allowlisting may be provided for eligible production integrations.

Until you have answers, write your integration so that a rejection from an address mismatch surfaces as an alert with the requestId attached, not as a generic retry.

How should you store and inject API keys?

The raw key is shown once. The dashboard banner says it plainly: "Key created. Copy it now. You won't see it again." What you do in the next thirty seconds decides how safe the key stays. The API security policy states that API keys are confidential credentials needing care appropriate to passwords, and that they should live in cloud secret managers, environment secrets, encrypted configuration stores or equivalent systems, with restricted access, and not in plaintext databases.

Where keys must never go

The same policy lists the places keys must not appear: public repositories, publicly accessible HTML, browser-executed JavaScript, mobile application binaries, screenshots, public forums, public support channels, public documentation, and source-control repositories generally. If a secret is committed by accident, treat it as compromised. Deleting it from the latest commit does not remove it from history, so revoke or rotate it.

This has a direct architectural consequence. A verification call must come from your backend. If a web or mobile client needs a PAN check, the client calls your server, and your server calls StampMitra. Do not ship a production key to a front end.

Injecting from the environment

The quickstart uses an environment variable named STAMPMITRA_API_KEY. Keep that name, populate it from your secret manager at deploy time, and never default it to a literal.

# .env.local  (git-ignored; sandbox key only)
STAMPMITRA_API_KEY=sk_test_xxxxxxxxxxxx

curl -X POST "https://api-b2b.stampmitra.in/v1/verify/pan" \
  -H "Authorization: Bearer $STAMPMITRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"pan":"ABCDE1234F","name":"Rahul Kumar"}'

// Node.js 18+
const key = process.env.STAMPMITRA_API_KEY;
if (!key) throw new Error("STAMPMITRA_API_KEY is not set");

const res = await fetch("https://api-b2b.stampmitra.in/v1/verify/pan", {
  method: "POST",
  headers: { Authorization: `Bearer ${key}`, "Content-Type": "application/json" },
  body: JSON.stringify({ pan: "ABCDE1234F", name: "Rahul Kumar" }),
});

import os, requests

key = os.environ["STAMPMITRA_API_KEY"]
r = requests.post(
    "https://api-b2b.stampmitra.in/v1/verify/pan",
    headers={"Authorization": f"Bearer {key}"},
    json={"pan": "ABCDE1234F", "name": "Rahul Kumar"},
    timeout=15,
)

CI/CD and logs

Store the value in your pipeline's secret store and keep it out of build logs; the security policy asks for exactly that. Redact the Authorization and x-api-key headers in application logs and in any HTTP debugging proxy. The dashboard Usage and Logs pages accept a pasted sandbox key and state it is used only for that request and never stored, which is a good reminder to paste keys only into places that make that promise.

How do you rotate a key without downtime?

The dashboard offers Rotate and Revoke on every active key. The rotate confirmation is blunt: the old secret stops working immediately and is replaced by a new one, which is shown once. There is no documented overlap window in which both secrets are valid. So if your service reads one key at startup and you press Rotate during business hours, every instance still holding the old secret starts failing with 401 until it reloads.

The zero-downtime pattern

Use create-then-revoke instead of rotate when the service is live.

1. Create a new key with the same scopes and a name that carries a date, such as kyc-worker-2026-10.
2. Store it in your secret manager next to the current one.
3. Deploy or reload so every instance uses the new key.
4. Watch the key list. Each key row shows when it was last used, so confirm the old key's last-used time has stopped moving.
5. Revoke the old key.

Use the dashboard Rotate button when you are rotating an idle key, an environment with a short maintenance window, or in an emergency where an instant cut-off matters more than a few failed calls.

Make clients reload secrets

A rotation only helps if clients can pick up a new value. Read the key per request from a small in-memory holder that you can refresh on a signal or on a 401, rather than binding it into a long-lived object. A retry on 401 that re-reads the secret and tries once more handles a staggered rollout gracefully.

let key = process.env.STAMPMITRA_API_KEY;
async function call(body) {
  for (let attempt = 0; attempt < 2; attempt++) {
    const res = await fetch("https://api-b2b.stampmitra.in/v1/verify/pan", {
      method: "POST",
      headers: { Authorization: `Bearer ${key}`, "Content-Type": "application/json" },
      body: JSON.stringify(body),
    });
    if (res.status !== 401 || attempt === 1) return res;
    key = await loadKeyFromSecretManager(); // your own function
  }
}

How often?

The security policy asks you to rotate periodically according to your own requirements and promptly when compromise is suspected, a key is exposed, a repository becomes public, an unauthorized person gains access, someone with access leaves, or a security incident occurs. It does not set a fixed interval, so pick one that matches your internal policy and write it down.

What should you do the moment a key leaks?

Speed matters more than elegance. The security policy lists the expected actions: revoke the affected credential, generate a replacement, investigate unauthorized activity, inspect logs, secure the affected infrastructure, find the source, and notify StampMitra where the incident may materially affect its systems or data. The developer terms also say you must immediately rotate or revoke credentials you reasonably believe are compromised, and that StampMitra may revoke or rotate credentials itself where it has reason to.

A short runbook

1. Revoke first. In the dashboard, Revoke warns that anything using the key stops working immediately and that it cannot be undone. That is the point.
2. Issue a replacement with the same least-privilege scopes and deploy it.
3. Pull the usage picture. The Usage and Logs pages can show calls by service and by day, and the logs filter by service and by success or failure. Look for services you do not call, and for spikes.
4. For a production key, check wallet transactions for debits you cannot explain. A leaked live key can spend wallet balance on priced calls.
5. Remove the secret from wherever it leaked. If it went into git, rewriting history is not enough on its own; the key is already burned.
6. Write down what happened and which control would have caught it.

Do not send the secret to support

When you contact StampMitra support, the security policy asks that you not provide API secret keys, OTPs or passwords, and instead share sanitized logs, request identifiers, timestamps and error messages. Every error response carries a requestId, so quote that. The key prefix shown in the dashboard (the first characters followed by an ellipsis) is enough to identify which key you mean.

Revoked is not deleted

Revoked keys stay in the list with a Revoked status and a revoked timestamp, which helps your audit trail. The retention schedule notes that revoked, rotated, expired or compromised credentials may be retained in limited form for security, audit, fraud-prevention or forensic purposes.

How should a team share access to API keys?

Team access in StampMitra is organization-based. Roles are OWNER, ADMIN and MEMBER. Owners and admins can invite members by email and a role, change roles and remove members; the invite endpoint accepts only ADMIN or MEMBER, so an OWNER cannot be granted through an invite, and the last owner cannot be demoted or removed. Team management uses the logged-in dashboard session, not an API key, so a leaked API key cannot be used to add teammates.

Practical rules

• Keep the owner count small. Two owners protects you from a single point of failure without widening the blast radius.
• Make engineers MEMBER by default and promote deliberately. The docs describe invite and role changes as owner or admin actions.
• Remove people promptly when they leave. The security policy lists "an employee or contractor with access leaves" as a reason to rotate credentials, so removing the person is not the end of the task if they ever saw a raw key.
• Do not share one key across the team's laptops. Developers should each work with their own sandbox key, named after the person or the task, so a leak is attributable and individually revocable.

Who sees the raw key?

The raw secret appears once, to the person who creates or rotates it. The repository does not document whether other members can view or re-reveal it, and the platform says it will not show it again. So the safe workflow is: the creator immediately places it in the shared secret manager and nobody types it into chat. Production secrets should be reachable only by the deployment pipeline and a very small group.

Client projects and freelancers

The onboarding policy permits an individual developer to run an authorized client project, provided the client has authorized the integration and credentials are appropriately controlled. In practice, create a separate organization or key set per client, so that ending the engagement means revoking one key rather than auditing everything.

How do you get production access, step by step?

Production access is not a toggle. The dashboard's Production access page says it directly: choose the APIs you want to take live, StampMitra reviews each one before issuing a production key, and production access requires additional account and use-case verification. The onboarding policy adds that completing sandbox testing does not guarantee approval and that StampMitra may approve, reject, restrict or ask for more information.

The steps

1. Finish sandbox work for every product you plan to launch. Use real error paths, not just happy paths.
2. Open Production access in the dashboard. Each row is a production-gated service, such as pan.verify or the single estamp entry that covers the whole e-Stamp surface.
3. Select the APIs that are eligible. You can select a service that has not been applied for or one that was rejected earlier.
4. Describe your use case (required). You may add an expected monthly volume and an application URL.
5. Submit, then track the status.
6. When a row shows Approved, create a production key from the API Keys page with Production (sk_live_) selected. If the organization's KYC is not approved yet, the request is rejected and the reason is displayed.

The statuses you will see

Make the application easy to approve

The onboarding policy says production eligibility may consider completed onboarding, verified identity, a legitimate use case, security readiness, acceptable-use compliance and required documentation. Write a specific use case: who your end users are, which products you need and why, and how you protect data. Say what your key handling looks like. A good application mirrors the checklist you are about to read. Review the onboarding verification policy before applying, and the acceptable use policy before you design your flows.

Go-live checklist for sandbox to production

Use this table as a pre-launch gate. Each row names the evidence you should be able to show.

Why row 7 deserves a test

The most common go-live defect is a staging deployment that quietly uses a live key, or a production deployment that still carries the sandbox key. A sandbox key in production does not fail loudly: verification calls still return successfully against sandbox data, which can wrongly mark real customers as verified or not. A startup assertion catches this in seconds.

Cost awareness

Production calls are billed per successful call from your wallet, at the rates on the pricing page. For example, a standard verification such as PAN is ₹5 rupees per call and bank-account verification is ₹4 rupees per call, and e-Stamp calls are ₹5 rupees per call. Check the page for the current rate rather than copying these into your own documentation.

How do you test in sandbox and keep environments from mixing?

Begin with a sandbox key and the same request you plan to ship. The PAN verification guide and the Node.js and Python PAN walkthrough show the full request and response shape. Here is the sample response from the product data, including the referenceId that every call returns.

{
  "referenceId": "SMV-20260927-8F42K7",
  "pan": "ABCDE1234F",
  "type": "Individual",
  "valid": true,
  "registeredName": "RAHUL KUMAR",
  "panStatus": "VALID",
  "nameMatchResult": "MATCH",
  "message": "PAN is Valid"
}

What to test

• Happy path and a negative result. A PAN that is not valid still completes and is a billable verification in production, so confirm your code handles valid: false as data and not as an exception.
• Validation errors. A malformed PAN returns 400 BAD_REQUEST with a message such as "pan must match the format ABCDE1234F".
• Auth failures. Send a bad key and expect 401 UNAUTHORIZED. Send a valid key without the scope and expect 403 FORBIDDEN.
• Rate limit behavior. Confirm your retry code backs off on a 429 and gives up on a cumulative quota.
• Upstream failure. A 502 with code INTERNAL_ERROR means the upstream service was unreachable; retry with backoff and alert.

Use only the documented sample identifiers, not real customer data. The acceptable use policy advises against placing real personal or confidential data in sandbox unless expressly permitted.

A startup guard

Make the prefix check part of boot, and treat a mismatch as fatal.

const key = process.env.STAMPMITRA_API_KEY ?? "";
const isLive = key.startsWith("sk_live_");
const isTest = key.startsWith("sk_test_");
const env = process.env.APP_ENV; // "production" | "staging" | "development"

if (!isLive && !isTest) throw new Error("Unrecognised StampMitra key prefix");
if (env === "production" && !isLive) throw new Error("Production must use an sk_live_ key");
if (env !== "production" && isLive) throw new Error("Non-production must not use an sk_live_ key");

import os
key = os.environ.get("STAMPMITRA_API_KEY", "")
env = os.environ.get("APP_ENV", "development")
live = key.startswith("sk_live_")
if not (live or key.startswith("sk_test_")):
    raise SystemExit("Unrecognised StampMitra key prefix")
if (env == "production") != live:
    raise SystemExit(f"Key prefix does not match APP_ENV={env}")

Never print the key in the error message. Print only the first few characters if you must, which is how the dashboard identifies a key.

Which errors point to a key or environment problem?

Most key trouble shows up as one of five statuses. All use the standard envelope with code, message and requestId.

A short diagnostic order

When a call fails and you suspect the key, check in this order. First, is the right header set and is the value non-empty after your secret loader runs? Second, does the prefix match the environment you expect? Third, is the key Active in the dashboard, and does its last-used time move when you call? Fourth, does the key's scope list include the one named in the endpoint docs, for example verification.pan.read for /v1/verify/pan? Fifth, if you expect an allowlist, is the call leaving from the address you registered?

A 401 right after rotation

If errors begin within seconds of pressing Rotate, you have instances still using the old secret. Redeploy or refresh them. Do not "fix" it by rotating again, since each rotation invalidates the previous secret.

Send the right facts to support

Email [email protected] with the requestId, timestamp, endpoint and key prefix. Leave out the secret. The errors and handling guide lists retry rules for each class of failure.

What are the most common API key mistakes?

These patterns recur because they are easy to make under deadline pressure.

Mistakes in handling

• Committing .env to git. Even a private repo is a risk, and the policy treats an accidentally committed secret as compromised. Revoke it.
• Using a live key on a laptop. Developers need sandbox keys only. Production keys belong to the deployment pipeline.
• One key for everything. A single key shared by a KYC worker, an e-Stamp order service and a dashboard script means one leak exposes all three, and revoking it stops all three.
• Embedding keys in a front end. A web or mobile client that calls StampMitra directly exposes the key to any user who opens developer tools or unpacks the app.
• Pasting keys into chat, tickets or screenshots. The policy lists screenshots and public support channels as prohibited places.

Mistakes in design

• Pressing Rotate on a live service with no overlap plan, causing a burst of 401s.
• Granting every scope "to be safe". Unused scopes are free attack surface.
• Treating allowlisting as a substitute for secret care. The policy says explicitly that IP allowlisting does not replace credential security.
• Forgetting the egress address changes. A migration to a new cloud region or a new NAT silently breaks an allowlisted key.
• Retrying a quota 429 in a loop.
• Assuming a sandbox pass means a production pass. Approval is a review, and sandbox responses may differ from live ones.

Mistakes in operations

• No owner for revocation. When a leak happens at night, someone must be able to revoke within minutes.
• Leaving old keys Active. Revoke keys that are no longer used; the list shows last-used times for exactly this audit.
• Leaving departed colleagues on the team. Remove the member and rotate any key they could have seen.
• Logging full request bodies. Bodies hold PAN numbers and names. Mask them, and keep only what you need, consistent with the purpose you collected the data for. If you handle personal data under India's Digital Personal Data Protection Act 2023, take advice from qualified counsel on your own obligations, because this guide is general information and not legal advice.

When should you use one key, many keys, or a different approach?

Use this guide's rules of thumb as a decision aid, not a mandate.

Use separate keys when

• Two services call different products. The scope sets differ, so the keys should too.
• Two environments exist. Sandbox and production are separate by construction, and staging should use a sandbox key.
• Different teams or clients own different integrations. You want separate revocation and separate last-used evidence.
• One workload needs an IP allowlist and another does not.

One key is acceptable when

• You are a solo developer running a prototype in sandbox. The cost of a leak is a lost sandbox quota, not live data. Still keep it out of git.
• A single service genuinely calls all the products with the same deployment and the same egress address. Even then, a narrow scope list beats "all".

Use the Rotate button when

• The key is idle or the service is in a maintenance window.
• You are responding to a leak and want the instant cut-off.

Use create-then-revoke when

• The service is live and cannot tolerate a burst of 401s.

When not to use API keys at all

A browser or a mobile app should not hold a production secret. If you need client-side verification, put a backend in front. If you build with an AI coding tool, put the key in the tool's secret or environment settings and not in the prompt; the Build with AI page makes the same point. The same applies to teammates using the MCP server or the SDKs: configure the key through environment variables, not source.

A worked scenario

A fictional lender, Kaveri Finserv, runs two services: an onboarding worker that calls PAN and bank-account verification, and an order service that books rent-agreement stamp paper for borrowers' property documents. They keep two production keys. The worker's key carries verification.pan.read and verification.bank-account.read. The order service's key carries services.read, orders.create, orders.read, payments.write, payments.read and documents.read. Each is allowlisted to its own NAT address, each is named with a quarter, and each rotates by create-then-revoke every quarter. A leak of the worker's key cannot place an order, and revoking it does not stop the order service. This is the shape of setup the KYC use case and the e-Stamp order flow guide assume.

How StampMitra Helps

StampMitra is a private LegalTech platform operated by Bani Global Industries LLP. It is not a government agency or a law firm, and nothing here is legal advice. What the platform does today, as documented, is this: a free self-serve sandbox with an immediately issued sk_test_ key, environment resolution from the key on the server, sandbox calls that are metered and logged without debiting your wallet, a lifetime sandbox quota that returns a clear 429 when exceeded, scoped keys with per-endpoint enforcement, per-key IP or CIDR allowlisting with PAN and RC defaulting to requiring one, and a dashboard where you can create, rotate and revoke keys and see last-used times.

On the production side, StampMitra reviews organizations and use cases per product before a production key can be created, and shows each application's status (submitted, under review, action required, approved, rejected or suspended) in the dashboard. Team management lets owners and admins invite members, change roles and remove access using the dashboard session rather than an API key. Every error comes back in one consistent envelope with a requestId, which makes support conversations faster and keeps secrets out of tickets.

A few honest limits. The sandbox quota number is not published in the documentation, and the pricing page and home page describe sandbox volume differently, so confirm your own allowance with support. The allowlist configuration path and the exact response for a blocked address are not documented in the public pages yet. Self-serve webhook endpoint registration is also marked as coming soon, so those endpoints are configured internally by StampMitra for now.

On what's next, the plans are directional and not promises. We intend to make key governance more visible, for example by documenting allowlist setup alongside the key creation flow and by making the quota explicit in the dashboard. The goal is that a team can run the checklist above from public docs alone.

To start, create a free sandbox account, follow the quickstart, and read the authentication reference. For questions about key handling or allowlists, write to [email protected] with your requestId, never your secret. Related reading includes the security policy and the developer privacy policy.

API reference at a glance

{
  "referenceId": "SMV-20260927-8F42K7",
  "pan": "ABCDE1234F",
  "type": "Individual",
  "valid": true,
  "registeredName": "RAHUL KUMAR",
  "fatherName": "SURESH KUMAR",
  "panStatus": "VALID",
  "panStatusCode": "E",
  "panStatusDescription": "Existing and valid PAN",
  "nameMatchResult": "MATCH",
  "nameMatchScore": "100",
  "aadhaarSeedingStatus": "y",
  "aadhaarSeedingStatusDescription": "Aadhaar linked",
  "lastUpdatedAt": "2023-04-01",
  "message": "PAN is Valid"
}

Frequently asked questions