Get access#

What has to exist before your first request#

1. An account record#

   Your commercial entity — the thing we contract with and bill.

2. A distribution configuration on it#

   Which channel you see, your credit limit, your billing terms. Without this no key can be issued at all, so it is not an afterthought.

3. An API credential#

   The key itself, plus your callback signing secret.

What you supply#

For the account:

For the distribution configuration, agreed commercially rather than submitted on a form:

What you get back#

{
  "id": "0f1c9e2a-3b47-4b1e-9d55-0e2a7c8f1b23",
  "keyPrefix": "dk_live_9fQ",
  "apiKey": "dk_live_9fQx7Kd2m1RtY0vBn4pLcJ8sWaZeH3uG6iO5yT7rXk",
  "callbackSigningSecret": "whsec_7bQ1x9KdmR2tY0vBn4pLcJ8sWaZeH3uG6iO5yT7rXk",
  "createdAt": "2026-07-29T09:15:22Z"
}

And one non-secret: your Razorpay public key id#

Issued separately from the response above. You need it to open Checkout against an invoice's razorpayOrderId — see Invoices.

It is a per-integrator constant rather than per-invoice, which is why no API response carries it. It is a public value and safe to ship in a browser bundle, unlike either secret above.

The callback signing secret#

Two things about it that are easy to get wrong:

1. It belongs to the account, not to the key. Issuing a second API key returns the same signing secret rather than rotating it — deliberately, so minting a key never silently breaks a callback receiver that is already running.
2. There is no rotation endpoint. Once generated it is fixed. Changing it is a conversation with us, not an API call.

Without a secret on file, supplying a callbackUrl on a booking is rejected with 400. We will not send unsigned callbacks.

If you lose your API key#

There is no recovery and no rotation endpoint. Roll it instead, in this order:

1. Issue#

   Ask us for a new credential. You get a new dk_live_ key; the signing secret is unchanged, so your callback receiver keeps working.

2. Deploy#

   Ship the new key everywhere.

3. Revoke#

   Ask us to revoke the old credential by its id. It stops authenticating immediately — every request with it returns 401.

An account can hold several active credentials at once, which is what makes this zero-downtime. Revoking before deploying is the way to take yourself offline.

Multiple keys, on purpose #

Issue a separate credential per deployment — production, staging, the nightly catalogue sync.

Each carries its own keyPrefix, so a log line tells you which one made a call. Each has its own rate-limit bucket, so a runaway batch job cannot starve your live booking path. And each can be revoked without touching the others.

Two ways to be blocked#

They are not the same thing and the symptoms differ:

Next#

Authenticate and call GET /v1/ping, then walk the Quickstart.