zenly/Documentação
Buscar na documentação
Português
API referenceGetting started

Authentication

One credential, sent as a bearer token. An organization owner mints it, and it carries the authority of an owner, so where you store it matters more than how you send it.

cURL
curl https://api.zenly.app.br/v1/organization \
  -H "Authorization: Bearer $ZENLY_API_KEY"

What a key is

A key is a token beginning zk_ followed by 32 random bytes. It belongs to one organization, and that is what makes an organization parameter unnecessary: the key decides whose data you are reading, and no key can reach another tenant’s records.

The token is shown once, in the response to the request that mints it. Zenly stores only its SHA-256 hash, so nobody can read it back to you later, including us. Losing it means minting a replacement.

The first characters stay visible in Zenly as the key’s prefix, for example zk_a1b2c3d4, so an owner can tell keys apart in a list without ever seeing a whole one.

A key can do anything an owner can do

There are no scopes in this version. A key has owner authority across every location the organization has, and there is nothing to configure per key. Two practical consequences:

  • Server-side only. Never ship a key in a browser, a mobile app or anything else a member could read. If your website’s signup form needs to create a client, put your own endpoint in front of it and keep the key on your server.
  • One key per integration. Revoking is the only way to cut off a key, and revoking one that three systems share breaks all three. Separate keys make that a decision rather than an accident.

Expiry and revocation

A key can be given an expiry at mint time, after which it stops working on its own. Without one it lives until revoked. Revocation takes effect on the next request and cannot be undone, so a key that is called every minute stops within the minute.

A key outlives the person who minted it: deactivating that owner does not revoke their keys. Revoking is always explicit.

The API is on Pro and above

Minting is refused below Pro, and so is every request, checked on each call rather than only at mint time. A downgrade therefore stops a live integration with a 402, which is deliberate: the feature follows the plan rather than the moment the key happened to be created. See Pricing for the tiers.

What needs no key

The contract itself: the OpenAPI document and its schema files answer unauthenticated. Everything else under /v1 requires a key and refuses the request without one.