What you need

What has to be in place in a TimeLog account before an API call works: the subscription, API access, an integration user and the credentials.

Before your first call works, a few things have to be in place in the TimeLog account you connect to. Use this page as a checklist with the account's TimeLog administrator.

Your TimeLog subscription

Not yet documented. Which TimeLog plans include API access, whether the integration user needs a paid user licence, and which modules unlock which parts of the APIs are not yet documented here. Ask your TimeLog contact.

The REST API already documents, per operation, when a call also depends on the account's product, licence plan, modules or features. See Licences, modules and account features.

API access switched on

API access has to be enabled for the account. If it is not, the APIs tell you so:

API	What you see
Transactional	Error `20008`, `API is not Activated: Please Enable`
Reporting	The call is refused as access denied (HTTP `401`)

In both cases, ask your TimeLog administrator. Retrying does not help.

Not yet documented. Where API access is switched on, who can change it, whether it is on by default for new accounts, and whether it affects the REST API are not yet documented.

An integration user

Who an integration acts as depends on the API:

API	Who the integration acts as	What you need
REST	The TimeLog user who created the personal access token	A user whose privileges match what the integration does.
Transactional	The TimeLog user whose user name and password call GetToken	A dedicated TimeLog user.
Reporting	No user: the account	An administrator who sets the Reporting API ID and password.

For REST and Transactional, use a dedicated integration user. Do not use a person's own login. Actions are then attributed to the integration, and you can change its access without affecting a person. For REST, give that user exactly the privileges the integration needs, and test with that user rather than an administrator: see Recommendation: a dedicated integration user.

To open the Reporting API settings and set the API ID and password, use a user with the standard system administrator role or similar.

Not yet documented. The recommended roles for the REST and Transactional integration user, and which role lets a user create personal access tokens, are not yet documented.

Credentials per API

API	Credential	Where it comes from
REST	A personal access token	Generated by the integration user. See REST authentication.
Transactional	A token from GetToken	Requested with the integration user's user name and password. See Transactional authentication.
Reporting	`siteCode`, `apiID` and `apiPassword`	System Administration > Integrations and API > Reporting API settings. See Reporting authentication.

The Reporting API ID and password are one set per account, set by an administrator. They are not a TimeLog user login. A change applies from the next call, so changing them affects every system that uses them.

You also need the account's address. See Find your base URL.

Security checklist

Use one credential per integration. If one integration is retired or compromised, you can revoke or change its credential without breaking the others.
Store credentials as secrets. Keep them in a secret store or an environment variable, never in source code, logs or URLs.
Call over HTTPS. Both SOAP APIs refuse plain HTTP calls.
Know what the Reporting credentials expose. They give access to all of the account's reporting data, including personal data, regardless of any user's permissions.

Was this page helpful?