Every /v1 endpoint authenticates with an API key sent as a Bearer token:
There is no other authentication for the API surface — no query-string
keys, no cookies. (The dashboard uses its own cookie session; that surface
is separate from this API and not covered here.)
Keys
- Format — new keys are prefixed
sq-arca-. Older ws- keys remain
fully valid; the dashboard marks them LEGACY.
- Storage — keys are shown once at creation and stored hashed.
Recently created keys can be re-revealed from the dashboard; older ones
cannot, so treat every key as show-once.
- Multiple keys — an account can hold several labeled keys (for
example one per app). All keys share the same account-level quota.
- Rotation — rotating from the dashboard revokes the old key and
issues a new one in a single step.
A key identifies your community account. Don’t embed it in client-side
code or share it — anyone holding the key spends your quota.
Account states
A syntactically valid key can still be refused when the account behind it
is not in good standing:
GET /v1/me is the cheapest way to check that a key works and see which
account (and key label) it maps to.