One API key should not open everything

Every wallet pass platform hands you an API key on day one. Almost none of them ask what that key should be allowed to do. The answer is usually “everything”: every pass, every holder, every write, forever, until someone remembers to revoke it.

That is fine for a solo developer testing on a Tuesday. It is not fine the moment a second party touches your account: an analytics vendor who only needs to read, an event website that only needs to issue tickets for one pass, an agency's client who wants their own integration without seeing the agency's other clients. Each of those parties gets the same master key, and your security posture becomes the sum of everyone's laptops.

Pass Studio keys now carry a scope. Here is what that means in practice.

Read-only keys

A read-only key can list passes, page through the holders of a pass, look up a holder, read loyalty balances, and check a batch job. It cannot issue, update, revoke, award points, or redeem. Any write returns a 403 with a machine-readable code, before the request touches anything.

Give this key to the dashboard vendor, the data warehouse sync, the reporting contractor. If it leaks, the worst outcome is that someone reads data they should not have. Nobody issues ten thousand passes on your credits.

Per-pass keys

A key can be restricted to one pass, or to a named list of passes. Every endpoint that addresses a pass checks the restriction, including the ones that arrive through an instance id or a barcode rather than a pass id, so there is no side door.

This is the event-site key. The ticketing page for the spring festival gets a key that can issue on the festival pass and nothing else. When the festival is over, revoke it. Your loyalty program, your membership cards, and next season's event were never reachable from that key.

For agencies, it is the client-vendor key. A client's CRM consultant gets a key scoped to that client's passes inside that client's workspace. The agency's other clients are not merely hidden; they are outside the key's authority.

Rotation with an overlap

Keys should be rotated on a schedule and after any staff change. The obstacle has always been the gap: the old key stops, the new key is not deployed everywhere yet, and something in production breaks at the worst moment.

Rotate a Pass Studio key and you get a replacement with the same label and scope, while the old key keeps working for 24 hours and then expires on its own. Deploy the new key at your pace inside that window. The settings panel shows the countdown, and every key shows when it was last used, so a key that has gone quiet is easy to spot and retire. Rotation is available to everyone and forced on no one.

What this looks like elsewhere

We checked how the incumbent handles the same problem, because a claim like “clear differentiator” should be verifiable. PassKit's long-lived API token is described in their own documentation as “full and permanent API access to your account”. Their key-and-secret credentials carry no scope either. Their rotation mechanism is that old SDK credentials stay valid for 30 days, account-wide. Their web portal is a single login per account; their advice to agencies whose staff need access is to share the password, or to open a separate account per client.

None of that is unusual in this category. It is simply the model most platforms started with and never revisited. We think the key should carry the permission, not the person holding it.

How it fits the rest of the account

Scopes sit on top of boundaries that already existed. Keys belong to a workspace and can never see another workspace. Teams have roles. Every key is hashed at rest, shown once, and revocable in one click. Every key-authenticated call carries rate-limit headers, and every list endpoint paginates the same way. The scope is one more thing the key knows about itself, and one less thing you have to trust a third party to get right.

Getting started

Open Settings, create a key, and pick its scope: full or read-only, all passes or a chosen few. Existing keys keep working exactly as before; they are full-scope keys, and you can replace them with narrower ones on your own schedule using rotation.

The full reference, with the error codes a scoped key returns, is in the API guide. If you are an agency, the organizations page explains how keys, workspaces, and billing fit together. The side-by-side with PassKit is on the comparison page.

Sources: help.passkit.com articles 5743688 (long-lived API tokens) and 5360004 (multiple portal users), read September 2026.