Skip to content
Thirdlane

API Keys

API Keys

API keys are unique identifiers used to authenticate and authorize access to an API (Application Programming Interface). They act like a password to control and monitor the usage of the API, ensuring that only approved users and applications can access specific functionalities and data.

In this section, you can manage API keys that other applications can use to access our services.

All you have to do to create an API key is specify its name, and the system will autogenerate it for you.

Once the key is generated, it will be shown to you. You must save it or enter it into the application that will be using it. For security reasons, it won’t be shown again, but if lost, it can be deleted and generated anew.

Who can create keys and key scope

A key inherits the scope of the administrator who creates it, and can optionally be limited to a single tenant:

  • Tenant administrators can only create keys scoped to their own tenant.
  • Global administrators can create global keys (platform-wide access) or bind a key to a single tenant. A dedicated API Keys (Global) screen is available for this under platform management.

When a key is bound to a tenant, it can act only within that tenant: requests aimed at another tenant, or at global/platform operations, are rejected. Leave the tenant set to Global for platform-wide access.

The root user cannot create API keys. Because a key authenticates as its owner and does not expire, a root-owned key would be an unattributable, maximum-privilege credential. Create keys under a named administrator account instead so they have a bounded scope and can be revoked individually.

Zapier Based Integration

When configuring Thirdlane integration in Zapier, you will need to provide the “pbx_host” parameter. This is the hostname or IP address of your Thirdlane PBX system. Providing this information allows Zapier to connect and interact with your PBX system for automation tasks.

Best practices

  • Create one key per integration. Separate keys let you revoke a single application’s access without breaking every other integration.
  • Store keys as secrets. Treat a key like a password - keep it out of source control, shared documents, and screenshots. If a key is exposed, delete it and generate a new one.
  • Scope keys as narrowly as possible. Bind a key to a single tenant unless the integration genuinely needs platform-wide access, and create keys under a named administrator rather than a high-privilege account.
  • Rotate and prune. Delete keys for integrations you no longer use, since keys do not expire on their own.