3 min lesson
API keys: personal keys, account keys, and how requests stay trusted
Personal and account API keys, request validation, dedicated outbound IPs, and the Frontline public API docs.
Two key types exist in Frontline, and they are not interchangeable.
Personal keys live under Settings → My settings → Bring your own Agent. They are scoped to you. The CLI, Max commands, and most write operations need this type. Five per person. Create, copy, delete.
Account keys live under Settings → Account settings → Developer. They are for the public API as the account: scripts, Postman, a dashboard, an integration that should not act as a specific user. You name the key so you remember where it is used. You can copy, rotate, or delete it.
Docs for every endpoint sit here: Frontline public API reference.
When do I use which key?
Use a personal key when a human or a coding agent is doing work in Frontline: building a workflow, assigning a playbook, creating a custom tool.
Use an account key when a system calls Frontline on behalf of the firm. Harrington’s data warehouse pulling People overnight is an account key named “Warehouse.”
If a CLI command fails with unauthorized, switch to a personal key. If a server-to-server job should not be tied to James’s user, use an account key.
What is the secret key for request validation?
On the same Developer page, Secret key for request validation is the shared secret your receiving system uses to check that a request really came from this Frontline account.
Frontline signs outbound requests with that secret. Your server verifies the signature before it trusts the body. Generate it once, copy it, and store it in your vault. If you regenerate, the old secret stops working and every integration that checks the signature must be updated.
This is the check you want on a webhook receiver that creates a Deal when a mandate form is submitted, or on any endpoint that should only accept traffic from Frontline.
What are dedicated outbound IPs?
Dedicated outbound IPs routes this account’s outbound API calls and tool requests through a fixed set of IP addresses.
Turn Use fixed IP addresses on when a vendor or your own firewall only accepts known IPs. Custom tools, API nodes in workflows, and similar outbound calls then leave from those addresses.
Leave it off when the destination does not filter by IP.
How should Harrington set this up?
One personal key per person who uses the CLI or Bring your own agent. One named account key per system. Request validation on before any public receiver goes live. Fixed IPs on only if the portfolio vendor or the bank API requires a whitelist.
Keep the public API reference bookmarked. When Max or Claude builds a custom tool against Frontline itself, that is the contract they should read.