Skip to main content
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.