API Keys
API keys let external systems and scripts call the Ascent REST API on your organization's behalf without logging in as a person. Each key carries its own scopes (which resources and actions it may use) and an optional expiry, so you can grant exactly the access an integration needs and revoke it at any time.
Minting API keys requires a plan that includes API access. Managing keys (creating and revoking) is limited to the Owner and Admin roles — other roles that open the page won't be able to load or change keys, so ask an organization owner or admin if you need one.
Navigate to API Keys
Go to Settings → Security & API → API Keys (/settings/security/api-keys). The page lists every key in your organization,
shows the scopes each one carries, and provides the actions to create and revoke
keys.
How API keys authenticate
A request authenticates by sending the key as a bearer token:
Authorization: Bearer ask_…
Every Ascent API key begins with the ask_ prefix. Because a key authenticates
as the organization rather than a person, keys are exempt from interactive
sign-in policies (such as MFA prompts) — keep them secret and scope them
tightly.
Create a key
- Click Create API key.
- Give the key a descriptive Name (for example, "Reporting integration") so you can recognize it later.
- Optionally set an Expires date. Leave it blank for a key that never expires; if you set one, it must be in the future.
- Choose the key's Scopes:
- Tick Full access (all scopes) to grant the key every permission your organization has. Use this sparingly.
- Otherwise, select individual
resource.actionscopes (for example,tickets.read,invoices.create). Scopes are grouped by resource so you can pick just what the integration needs. At least one scope is required.
- Click Create.
Copy the secret immediately
When the key is created, Ascent shows the full secret token once. Copy it and store it in your integration's secret manager right away — you will not be able to view it again. If you lose it, revoke the key and create a new one.
After creation, the list only ever shows the key's prefix (for example,
ask_xxxxxxxx…), never the full secret.
Review keys
The API Keys table shows, for each key:
| Column | Meaning |
|---|---|
| Name | The label you gave the key |
| Key | The key's prefix (the full secret is never shown again) |
| Scopes | The granted scopes, or Full access for a wildcard key |
| Last used | When the key last authenticated a request, or Never |
| Status | Active, Expired (past its expiry date), or Revoked |
The Last used column is helpful for spotting keys that are no longer in use and can be safely revoked.
Revoke a key
Click the Revoke (trash) action next to a key to disable it. Revocation takes effect immediately — any system still using that key will start receiving authentication failures, so update or remove the integration first. Revoked keys remain in the list for reference but can never authenticate again.
Auditing
Creating and revoking API keys is recorded in the audit log, including the key's name and scopes, so you have a record of who issued or removed access and when.
Security recommendations
- Grant the narrowest scopes an integration needs rather than full access.
- Set an expiry for short-lived or third-party integrations.
- Use a separate key per integration so you can revoke one without affecting the others, and so Last used stays meaningful.
- Rotate keys periodically by creating a replacement, switching the integration over, and revoking the old one.
- Store secrets in a secret manager, never in source control or shared documents.