Publishable or secret key: which goes where?
What each key may do, why one is safe in a page and the other never is, and which to use where your code runs.
Checked 8 October 2026 About 3 minutes View as Markdown
The short answer
The publishable key goes in the browser: it reads what is published and takes bookings. The secret key reads customers and payments, so it stays on a server.
- Publishable: published content, free times and booking.
- Secret: every booking and payment, on a server only.
- A live publishable key works only from the websites you list.
Two keys, two places
Publishable pk_ |
Secret sk_ |
|
|---|---|---|
| Lives in | the page, where anybody can read it | your server, where nobody can |
| Reads published pages, services, staff and free times | yes | yes |
| Takes a booking | yes | yes |
| Reads, cancels, moves or pays for one booking | with its token | yes |
| Lists every booking | no | yes |
| Reads payments, or starts any other checkout | no | yes |
Why a publishable key is safe to publish
Anything in a web page can be read by whoever opens it, so a publishable key is built to be read. It can only do what any visitor could: read what is published and book.
- Each address is limited. Writes from one address are held to
10/min, so one visitor cannot fill a diary. - A live key works from your websites only. It carries the list of
websites it may be used from, and a browser on any other site is refused with
origin_not_allowed. The dashboard does not make a live one without a website on its list. - A customer's own booking needs its token. Reading, cancelling, moving or paying for it takes the manage token handed to the customer who made it, and to nobody else.
It is still a key. A script can send any website it likes as its origin, where no browser checks, so a copied key can make requests that count towards your monthly allowance. That is why everything it can do is something any visitor could do anyway.
Why a secret key never goes near a browser
A secret key lists every booking, with each customer's name, email address and the time they will be where, and reads every payment. In a page, it is all of that handed to whoever opens the network tab.
Keep it in your server's environment settings, never in code that is sent to a
browser. The SDK refuses to build a client with a secret key wherever a
window exists, so the mistake fails on your own machine first.
Which to use where
| Where the code runs | Key |
|---|---|
| A page in the browser | publishable |
| Your server, or a site built ahead of time | secret, or publishable for what is published |
| A webhook handler | neither: it checks the endpoint's signing secret |
If a project keeps its content off the browser, a publishable key is refused
with browser_reads_not_allowed when it reads pages, and the reading moves to
your server with a secret key.
Looking after keys
A key is shown once, when it is made, and kept in a form it cannot be recovered
from: a lost key is replaced, never looked up. A revoked key stops working at
once. A project can hold 25 keys in use. Test keys,
pk_test_ and sk_test_, read what live ones do and every page's draft too,
and what they book or pay is test data that no customer sees and no report
counts, paid at your provider's test mode.
Keys and allowed websites has the details, and How to verify a webhook covers the third secret.
Questions people ask next
Can a publishable key read drafts?
A test key can, and a live key cannot. A live key, publishable or secret, reads only what is published. A test key reads every page as its draft was last saved, so anybody who can open a site using one can read that unpublished work.
Can a publishable key cancel a booking?
Only with that booking's token. Cancelling or moving one booking needs its manage token, which only the customer who made it was given.
Why does my publishable key answer origin_not_allowed?
The website is not on its list. Add it the way a browser sends it: the scheme and the host, and a port if it has one, with no path and no trailing slash.
What if a secret key leaks?
Revoke it and make another. A revoked key stops working at once. Keys are kept in a form that cannot be read back, so a new key is the only way to have one again.