Authentication

Every request carries a credential in the Authorization header. AbleTime has two kinds, and they answer different questions: an API key acts for your organization, and a personal access token (PAT) acts for one person.

http

Authorization: Bearer <your-credential>

The Developer tab under Settings > Integrations shows the base URL and links to the API Reference.

Organization API keys

An API key is the credential most integrations use. It belongs to the organization rather than to whoever created it, so it keeps working when people join or leave.

Creating one

Go to Settings > Integrations > API Keys and click Create API Key. You choose its name, the grants it carries, and optionally an expiry date. Only an administrator or owner can create or revoke keys. If Integrations is greyed out in the sidebar, it is available on the Pro plan.

In the Create API Key dialog, Name is required and at least one grant must be ticked; grants are fixed at creation and cannot be changed later. Expiry is Never until you pick a date, after which the key expires at the end of that day; Clear removes the date. Click Create Key.

The key is shown once, in the API Key Created dialog, at the moment you create it. AbleTime stores only a hash of it and cannot show it again. Use the copy button and put it straight into your secret store; if you lose it, revoke the key and create another.

Afterwards the list shows each key's name, key prefix (a short non-secret fragment that lets you tell keys apart), grants, creation date, expiry and status. Status is Active, Expired or Revoked. Click Revoke on a key and confirm; revoking takes effect immediately and also stops any webhooks bound to that key. Revoked keys stay in the list.

Grants

A grant is a single named permission. A key carries a fixed set of them, chosen when you create it, and every endpoint states which grant it requires. A key with no grant for an endpoint is refused even though the key itself is perfectly valid.

Grant	Allows
Time entries: read	Reading time entries and timers, and binding webhooks for time entry events under Settings > Integrations > Webhooks
Time entries: write	Creating, updating and deleting time entries, and operating timers
Tasks: read	Reading tasks, and reading epics, and binding webhooks for task and epic events under Settings > Integrations > Webhooks
Tasks: write	Creating and updating tasks, everything on a task, and creating and updating epics
Epics: read	Shown in the picker as viewing epics; reading an epic is governed by Tasks: read
Epics: write	Shown in the picker as creating and updating epics; writing an epic is governed by Tasks: write
Milestones: read	Reading milestones, and binding webhooks for milestone events under Settings > Integrations > Webhooks
Milestones: write	Creating, updating and deleting milestones
Comments: read	Reading a task's comments, including their content, and binding webhooks for comment events under Settings > Integrations > Webhooks
Billing: read	Reading invoices, and binding webhooks for invoice events under Settings > Integrations > Webhooks
Billing: status	Moving an invoice to a new status
Projects: read	Reading projects
Clients: read	Reading clients, and expanding a project's client
Users: read	Reading users, and expanding a project's members
Calendar entries: read	Reading calendar entries, with a personal access token
Calendar entries: write	Writing calendar entries, with a personal access token

Give a key the smallest set that does its job. A key that only reports on hours needs reading grants and nothing else.

The picker also offers Epics: read and Epics: write, but epics are governed by the task grants. Reading an epic needs Tasks: read; creating, updating, deleting or changing the state of one needs Tasks: write.

Personal access tokens

A personal access token belongs to one person. Each person mints their own from their profile, under API Access, where the screen calls it a Personal Access Key. You hold at most one per organization; if you belong to several organizations, each has its own key, managed from that organization's session. Rotating replaces the old token immediately.

Click Create access key. The key is shown once, in the Access Key Created dialog, with a copy button. Afterwards the panel shows only the key's prefix, Active, and the date it was created. Rotate creates a new key and your existing key stops working immediately; any integration using the current key needs the new one.

A token carries that person's identity and their role in the organization. It carries no grants at all, because what it may do is decided by who its holder is and by which projects they belong to, exactly as it would be in the application.

Personal access tokens exist for work that is inherently about one person. Calendar entries are the clearest case: they hold proposed time a person has not yet committed, so they are reachable only with that person's own token, never with an organization key.

Your organization must also have agent access enabled for personal access tokens to work. Without it a valid token is refused. An administrator or owner turns it on with the Agent access (MCP) switch at the top of Settings > Integrations > API Keys. You can still create your key before then; it starts working as soon as agent access is enabled.

Choosing between them

	API key	Personal access token
Acts for	The organization	One person
Prefix	`atk_`	`apt_`
Created in	Settings > Integrations > API Keys	Your profile, under API Access
How many	As many as you need	One per person, per organization
Permissions	The grants you assign	The holder's role and project membership
Survives the creator leaving	Yes	No
Reaches calendar entries	No	Yes

Endpoint shapes, status codes, and request fields are in the API Reference.