IntegrationsRegister an external system

Register an external system

Registers a new external system and returns it with its new ID.

Creates the "other side" an integration links TimeLog objects to. Do this once per integration (per account), store the returned ID, and use it as ExternalSystemID when you write external keys on time registrations, projects and tasks. TimeLog does not deduplicate: every call creates a new system, even with a name that already exists.

Use it to:

  • First run of a new integration: register your system, persist Properties.ID in your own configuration.
  • One system per counterpart: an integration syncing two ERPs registers two systems so their keys never collide.

Not for:

  • Setting up a TimeLog built-in finance/payroll integration — creating its integration handler registers the system automatically.

Behaviour:

  • Not idempotent.
  • Not safe to retry blindly. A retry after a timeout registers a second system. List first and match on the ID you stored (or, failing that, on name + description) before retrying.
  • Duplicates: None — names are not unique and are not checked.
  • Changes are visible to the next read immediately.

Call first: GET /v1/external-systems

Next: PUT /v1/time-registration/{timeRegistrationID}/external-keys, PUT /v1/project/{projectID}/external-keys, PUT /v1/task/{taskID}/external-keys

See also: PUT /v1/external-systems/{externalSystemID}

Not yet documented: examples (success).

curl -X POST "https://app3.timelog.com/your-account/api/v1/external-systems" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -d '{
  "Name": "John Doe",
  "Description": "example_string"
}'
{
  "Properties": {
    "ID": 123,
    "Name": "John Doe",
    "Description": "example_string",
    "IsSystemExternalSystem": true
  },
  "Links": [
    {
      "Href": "example_string",
      "Rel": "example_string"
    }
  ],
  "Actions": [
    {}
  ]
}
POST
/v1/external-systems
POST
Base URLstring

Target server for requests. Edit to use your own host.

Bearer Token
Bearer Tokenstring
Required

OAuth 2.0 bearer token, sent as Authorization: Bearer <token>. JWT and reference tokens are both accepted. The token must carry the required scope (default tlp). The token's sub claim is the acting user. A token WITHOUT sub (client-credentials) acts as the system service user. If the sub user cannot log in (inactive, locked, deleted), the request is rejected with 401 — it is no longer let through without a user. > Not yet documented: how to obtain a token. > Not yet documented: token lifetime.

OAuth 2.0 bearer token, sent as Authorization: Bearer <token>. JWT and reference tokens are both accepted. The token must carry the required scope (default tlp). The token's sub claim is the acting user. A token WITHOUT sub (client-credentials) acts as the system service user. If the sub user cannot log in (inactive, locked, deleted), the request is rejected with 401 — it is no longer let through without a user. > Not yet documented: how to obtain a token. > Not yet documented: token lifetime.
Content-Typestring
Required

The media type of the request body

Options: application/json
Namestring
Required

Display name of the external system. Not unique: sending an existing name creates a second system with that name. - null, empty or whitespace-only — 400 "'Name' must not be empty." Built-in TimeLog integrations resolve key mappings by system name. Giving a system the name of another one makes those name-based lookups ambiguous (see ExternalSystemRead.Name). > Not yet documented: behaviour.

Min length: 1 • Max length: 200
Descriptionstring
Required

Free-text description of the external system. - null, empty or whitespace-only — 400 "'Description' must not be empty."

Min length: 1 • Max length: 255
Request Preview
Response

Response will appear here after sending the request

Authentication

header
Authorizationstring
Required

Bearer token. OAuth 2.0 bearer token, sent as Authorization: Bearer <token>. JWT and reference tokens are both accepted. The token must carry the required scope (default tlp).

The token's sub claim is the acting user. A token WITHOUT sub (client-credentials) acts as the system service user. If the sub user cannot log in (inactive, locked, deleted), the request is rejected with 401 — it is no longer let through without a user.

Not yet documented: how to obtain a token.

Not yet documented: token lifetime.

Body

application/json
Namestring
Required

Display name of the external system. Not unique: sending an existing name creates a second system with that name.

  • null, empty or whitespace-only — 400 "'Name' must not be empty."

Built-in TimeLog integrations resolve key mappings by system name. Giving a system the name of another one makes those name-based lookups ambiguous (see ExternalSystemRead.Name).

Not yet documented: behaviour.

Descriptionstring
Required

Free-text description of the external system.

  • null, empty or whitespace-only — 400 "'Description' must not be empty."

Responses

Propertiesobject

An external system registered in the account: a named "other side" (ERP, payroll, calendar, CRM …) that TimeLog objects can be linked to through external keys (ExternalKey.ExternalSystemID) and that integration conflicts are raised against. TimeLog's own built-in integrations create one per integration handler (named after the handler, e.g. "e-conomic <site>_v1"); an integrator can register its own with POST /v1/external-systems.

Linksarray
Actionsobject[]