Authentication

Every request carries the key. There is no token exchange, no expiry to refresh and no login step.

Sending the key

Either header is accepted. Send one, not both.

Headers

Authorization: Bearer lok_sbx_k7m2xqbd_xW9…
# or
X-Api-Key: lok_sbx_k7m2xqbd_xW9…

Both exist because integrators arrive with both habits, and an SDK that only knows how to set one of them should not be the reason an integration cannot be built. If both are present, Authorization wins.

What a key looks like

Four segments. Only the last one is secret.

Key anatomy

lok_sbx_k7m2xqbd_xW9pQ2…
│   │   │        └── the secret — 256 random bits, never stored
│   │   └── this key's public identifier, 8 characters
│   └── environment: sbx (Sandbox) or live (Production)
└── vendor tag, so a leaked key is greppable in your logs

The first three segments together are the key prefix — lok_sbx_k7m2xqbd. That part is public: it is what the dashboard displays, and it is safe in a log line or a support ticket. Localoy stores only a hash of the whole key, so nobody here can read your key back to you. A lost key is rotated, never recovered.

Sandbox and Production

Two environments, chosen when the key is created and fixed for its lifetime.

A key's environment is visible in the key itself — lok_sbx_… against lok_live_… — so a sandbox credential that has reached production configuration is obvious on sight rather than after the fact. It is fixed when the key is created: a key cannot be moved between environments, which is what makes the prefix trustworthy.

Sandbox is not a separate dataset

Both environments answer on the same base URL and read and write the same catalogue. The environment labels the credential, not the data — so an item created with a Sandbox key is a real item on your business, and deleting one with a Sandbox key deletes it for good. While you are still experimenting, use test externalId values you can recognise and clean up afterwards.

Every authentication failure is a 401

A missing key, a malformed key, an unknown key, a wrong secret, a revoked key and an expired key all answer the same 401 open_network_key_invalid, with the same message. This is deliberate: distinguishing them would let anyone probe which of your keys exist and which were revoked. It does mean the 401 will not tell you which mistake you made — call GET /ping and work from there.