Preview: this documentation describes the WorkLogx Public API V1. The V1 rollout to the production environment is not complete yet.

Authentication

Every request to the WorkLogx Public API is authenticated with an API key sent as a Bearer token.

Authorization: Bearer wlx_test_<prefix>_<secret>

#Key format

An API key has the form wlx_<environment>_<prefix>_<secret>:

Part	Meaning
`wlx_test_`	Key for the TEST environment
`wlx_live_`	Key for the production environment
`<prefix>`	12-character public identifier of the key
`<secret>`	Secret part, shown only once when the key is created

Environment	Base URL	Accepted keys
TEST	`https://api-test.worklogx.com/api`	`wlx_test_…` only
Production	`https://api.worklogx.com/api`	`wlx_live_…` only

A key from the other environment is rejected with 401 invalid_api_key. All examples in this documentation use the TEST environment.

Preview: the V1 rollout to production is not complete yet. Use the TEST environment for integration work.

curl https://api-test.worklogx.com/api/v1/customers \
  -H "Authorization: Bearer wlx_test_YOUR_API_KEY"

Status	`code`	When
401	`invalid_api_key`	Header missing, not `Bearer`, malformed key, unknown, revoked or expired key, or key from the wrong environment
403	`api_client_disabled`	Valid key, but the API client is disabled
403	`public_api_unavailable`	Valid key, but the Public API is not enabled for the organization
403	`insufficient_scope`	Valid key, but the API client lacks the scope required by the endpoint

The API does not accept WorkLogx user sessions or user tokens on /v1/ endpoints, only API keys. See Errors for the response format.

Use API keys only server-side. Never ship them in browser code, mobile apps or version control.
Store keys in a secret manager or encrypted configuration.
Give each integration its own API client, so it can be disabled or rotated independently.
If a key may have leaked, revoke it in WorkLogx (see API Keys & Scopes).