Identity & delegation
Authentication is the horizontal differentiator of the etg24 platform. Everything else — attribution, scopes, auditability — builds on one foundation: every integration actor is an explicit, named agent with its own key.
Self-service API key creation
API keys are created self-service inside the etg24 app — no support ticket, no sales conversation. You create a key per agent you operate, name it, and choose its scope.
Two axes: binding and access
Every key has two independent properties, chosen at creation time:
Binding — who the key acts for:
- User-bound — the agent acts on behalf of a person (a staff member of your company). Actions are attributed to that person’s agent.
- Tenant-bound — the agent acts on behalf of the company itself, for company-level automations that are not tied to one employee.
Access — what the key may do:
- Read-only — the key can run every query and no command. It cannot change data by construction. See Permission scopes.
- Read/write — the key can change data, scoped to the capabilities you grant; destructive actions are gated separately.
The two axes combine freely: a person-bound read-only key for an employee’s reporting agent, a tenant-bound read/write key for a company-level migration, and so on. Both choices are made once, at key creation time, and they determine how every action of that key shows up in the change log.
One key per agent
Agents do not share keys. Each agent you operate — a nightly sync, a support bot, a document processor — gets its own key. This is what makes per-agent attribution possible: you always know exactly which agent did what.
What this enables
- Granular disable — a misbehaving agent is disabled with one click, without touching the others.
- Clear responsibility — logs read “agent X changed Y”, not “the API changed Y”.
- Safe delegation — you can hand a scoped key to a contractor or an AI tool without giving away your account.
Next: Per-agent attribution — or jump to Key lifecycle for how keys are managed day to day.