General

Authentication

One credential type, created by you, in the dashboard. There is no OAuth flow to implement and no client to register.

Send the key

curl https://api.veruapis.com/v1/me \
  -H "Authorization: Bearer vak_live_8f3c2e8d1a4b_xK9mP2rQ7wL4nT6vB8yD0fH3jS5kA1cE"

What a key is

A key looks like vak_<env>_<id>_<secret>. The middle segment is an identifier that is safe to log and safe to paste into a support ticket. The last is the secret, shown once when the key is created and stored only as a hash after that. If you lose it, create a new key; nobody can recover the old one.

A key acts as the person who created it

Scopes narrow a key and never widen it, so it can never do more than its creator can. If that person is suspended or leaves the workspace, the key stops working and returns grant_revoked.

VeruSuite credentials do not work here

A VeruSuite session token, a personal API token or a platform key presented to this API is refused with 401 wrong_credential_type. That is deliberate rather than an oversight: keys issued here carry the permissions you chose, and a suite token carries all of them.

Keeping a key safe

  • Treat it as a password. Anyone holding it can do what it is scoped for.
  • Put it in your environment or a secret store, never in a repository. The vak_ prefix is registered with secret scanners, so a committed key gets reported, but that is a safety net rather than a plan.
  • Give each automation its own key with only what it needs, so revoking one does not stop the others.
  • Rotate on a schedule. Create the replacement, deploy it, then revoke the old one; the two work side by side in between.