Authentication

Every API request is authorized with a partner API key. Send it in the Authorization header using the Bearer scheme:

Authorization: Bearer ldg_live_…

API-key requests are for partner-level integration. This is different from the session (JWT/OTP) authorization used in the customer panel and must not be confused with it.

Do not pad the header value with whitespace

The value must be exactly Bearer (a single space) followed by the key. An Authorization header carrying leading or trailing whitespace or a line break is treated as invalid and the request returns 401; sending the header twice has the same result. This is a behaviour change: a trailing space used to be ignored.

Most HTTP libraries already trim the value, so this typically affects clients that build the header by hand (shell scripts, older SDKs). The response is a neutral 401, which makes it hard to diagnose — if you are certain your key is valid and still receive 401, check this first.

Key format

Keys start with a prefix:

Prefix	Usage
ldg_live_…	Live (prod) environment
ldg_test_…	Test environment

Note

The environment split of the key prefix and access to the test environment are clarified during onboarding. The ldg_test_ example above is a format illustration only; the exact value and test-environment details are provided to you at onboarding.

Previously issued ptk_ prefixed keys remain valid

API keys generated earlier with the ptk_live_… / ptk_test_… prefix continue to work. You do not need to take any action (no renewal, no replacement). The prefix is only a visible label showing the environment the key was generated for; authentication does not depend on it. The new prefix only affects keys you generate from now on.

Key management

• The key is shown in full only once, at creation time. Store it securely.
• If lost, it cannot be recovered; you must generate a new key.
• Only a visible identifier of the key (e.g., the last few characters) appears in listings.

Security

Never keep the API key on the client side (browser, mobile app) or in a public repository. The key is used only in server-to-server calls. If it leaks, generate a new key and revoke the old one immediately.

Unauthorized requests

Requests with an invalid, missing, or revoked key are rejected with 401 Unauthorized and a standard error response.