Developer
Create account API keys, manage request-validation secrets, and understand where the Frontline Public API and CLI fit into deeper integrations.
Use the new Public API for deeper integrations.
Use it when an external system needs to create, read, coordinate, or report on supported Frontline resources: agents, flows/workflows, billing/usage, and analytics.
Check which workspace behavior, access rule, credential, usage signal, or data-model surface the control changes.
What Developer is for
Developer is the API access surface for the account. The real screen shows API Keys, Account API Keys, Create API Key, copy/regenerate/delete controls, and a Secret key for request validation section.
This page exists for custom integrations, external systems, and implementation work that needs controlled API access.
How this connects to the Public API
Use Developer settings to create and rotate the credentials your implementation owns. Use the Frontline Public API when an external system needs programmatic access to supported assistants, flows/workflows, billing/usage, or analytics.
Keep this Academy page as the operating guide. For endpoint-level details, authentication format, and request examples, open the public API reference: https://frontline-public-api.redocly.app/api.
How this connects to the CLI
Use @getfrontline/cli from npm when the implementation needs terminal workflows, repeatable scripts, JSON output, profile switching, or Max commands: https://www.npmjs.com/package/@getfrontline/cli/.
Account-level API keys belong in Developer. Personal keys for external agent environments belong in Bring your own Agent.
Which surface to use
Use Developer for account-owned API access, production integrations, server-side jobs, and request-validation secrets.
Use Bring your own Agent and the CLI for user-scoped terminal work, external AI agents, profile-based scripts, and Max workflows.
What each control changes
Create API Key creates an account-level key. Copy moves the key into an implementation environment. Regenerate rotates access. Delete removes the key. The request-validation secret is used by receiving systems to validate signed requests from the account.
Treat keys as production credentials. Name keys by purpose, rotate them if exposure is suspected, and delete unused keys before they become hidden access paths.
Operational outcome
Developer settings make custom integration work inspectable. Teams can connect Frontline to their stack while keeping API access explicit, named, and revocable.
Operational playbook
Use this page to identify what the control changes, which source context it uses, who owns the result, and where to verify it.
Use the page to identify the trigger, source data, owner, visible result, and review point before changing production behavior.
Best practices
Start with the operational job before changing configuration. Name the owner, define the trigger or source context, and decide how the result should be reviewed.
Start with one workflow, message, record update, or Max task before expanding. The team should know what changed, who owns it, and how to pause or adjust it.
Troubleshooting
If the result is wrong, debug in this order: source data, permissions, connected tools, required fields, workflow logs, then any generated output used later.
When debugging, open the related CRM record, Max activity, workflow run, or integration log first. Fix the source data or rule before adding more automation.
FAQs
What does Developer control?
Create account API keys and manage request-validation secrets for custom integrations.
Where does the CLI fit?
Use @getfrontline/cli from npm when developers need repeatable terminal commands, JSON output, saved profiles, or Max workflows.
Who should use this page?
Workspace admins, implementation owners, and operators responsible for configuring access, account behavior, developer integrations, or the data model.
How should this page fit into onboarding?
Use it to understand the product surface, inspect real UI states, and connect the concept to daily operating workflows before configuring production behavior.
What should I verify before using this in production?
Verify ownership, permissions, source context, failure behavior, and the handoff path so teammates can trust what the system does next.