Authentication

A workspace can have up to 10 API keys, each named for what uses it. A request made with any of them acts on that workspace: its passes, templates and usage, and nothing else.

Send the key

Send it as a bearer token in the Authorization header of every request:

Authorization: Bearer wpk_…

Requests go over HTTPS only. A request without a key, or with one that isn't valid, is refused:

{
  "error": {
    "code": "unauthorized",
    "message": "Invalid API key",
    "requestId": "req_5be2410e…"
  }
}

Find it, and keep it safe

Keys are in the dashboard, under Settings, for the workspace's owner. Choose New API key and name it after what will use it, such as "Website" or "Spreadsheet sync". It's shown once, when it's made: copy it into your server's secrets, such as an environment variable, then.

• Give each integration its own key, so you can revoke or rotate one without stopping the others.
• Keep it on your server. Never put it in a web page, a mobile app or a repository: anyone with it can issue and revoke passes in your workspace.
• Give each environment its own workspace, such as one for testing and one for real passes, so a test key can never touch real holders.

Rotate or revoke it

To replace a key, for example if it may have leaked, choose Rotate beside it in Settings. The new key is shown once, and the old one stops working at once, so update what uses it straight away. To stop one for good, choose Revoke. Either way your other keys carry on, and each change is recorded in the Activity log.

What a key can't do

Some things are done by people in the dashboard, never with a key: your Apple and Google credentials, webhook endpoints, spreadsheet imports, and your workspace's members.