4D has three credential types. Which one you use depends on where the call is
made from:
Organization API keys
Every partner API call authenticates with a bearer header:
The key is bound to your organization. There is no org id parameter anywhere
in the API - your key is the tenancy. Isolation is enforced with
row-level security at the database layer, so a request can only ever read or
write rows belonging to your organization.
Treat org_ keys like passwords: server-side only, never in client bundles,
rotate if exposed.
Publishable tracking keys
Browser event tracking can’t hide a secret, so it doesn’t use one.
POST /v1/track authenticates with a publishable ek_live_… key that
ships in your client code, like an analytics measurement id. Abuse is bounded
by two controls on the key itself, not by secrecy:
- a per-key origin allowlist - events are only accepted from browser
origins you configured for the key;
- per-key rate limiting.
You issue and revoke tracking keys with your organization API key - see
Trigger an event.
Module credentials
Installed modules push events server-to-server via POST /v1/ingest with an
mk_live_… bearer credential plus an HMAC signature header
(x-4d-signature) and an Idempotency-Key. This surface is only relevant if
you’re building a 4D module; module documentation is provided during module
onboarding.
Error envelope
All authenticated surfaces return errors in one envelope:
Missing or invalid credentials are a 401; a valid credential without
permission for the operation is a 403 or, where the resource’s existence
shouldn’t be revealed, a 404. code values are the stable contract to
program against. 
