Skip to main content
Access is granted to a registered application, bound to one association. An application has three credentials.
  • Client ID (clientId), public identifier for the application.
  • Client secret: secret used with the client ID to issue an access token.
  • Application secret (apiKey), secret sent on every request as the x-zeam-auth header.

​
How each credential is used

​
clientId
string
Sent with the client secret to POST /v1/auth/token to obtain a bearer token.
​
clientSecret
string
Sent with the client ID to issue a token. Never sent on other requests.
​
x-zeam-auth
string
The application secret, sent as a header on every protected request alongside the bearer token.
In short: the client ID and client secret get you a token; the application secret is the x-zeam-auth header you send with that token.

​
How credentials are issued

Applications are registered by an association administrator in the Zeam business portal, under Settings → Application Registration. Registration returns the client ID, the client secret, and the application secret.
The client secret and application secret are shown once, at registration. Store them securely the moment they are issued. They cannot be retrieved again.
If you are an integrator without portal access, ask your association administrator to register an application and share the credentials with you through a secure channel.

​
Sandbox vs production keys

Sandbox and production credentials are separate and not interchangeable. Begin with sandbox credentials, then receive production credentials when you are promoted. See Production promotion.

​
Handling credentials safely

  • Use credentials only from server-side code.
  • Store them in a secret manager, not in source control.
  • Treat the application secret like a password; rotate it if it may be exposed.