Frontline Studio · Integrations · Interactive walkthrough

Connect APIs

Connect external systems to Frontline through safe API and webhook patterns, and use the Frontline Public API or CLI when you need programmatic access to supported platform resources.

Interactive walkthrough7 min

Public API

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.

AgentsWorkflowsAnalyticsBilling/usage

Academy guide Open API docs

Workflow node palette showing API Call as the integration node for external requests — Integration catalogConnectors agents can use
Check connector availability, connection status, and whether the tool maps to a real workflow or agent action.

Integrations

Choose the tools Studio can use.

Open the catalog, connect only the systems the operation needs, then use them in agents, workflows, or tools with a clear outcome.

Integration catalog showing connectors available when built-in tools are a better fit than a custom API call — Integration catalogConnectors agents can use
Check connector availability, connection status, and whether the tool maps to a real workflow or agent action.

What you will build

You will build a safe integration pattern that lets a workflow call an external system or send an outgoing webhook, then verify the response and route failures.

The example should use placeholder endpoints and sample payloads only. Never place secrets or private URLs in public Academy content.

When to use it

Use API Call or Outgoing Webhook when Frontline needs information from an external system, must notify another tool, or should hand off a structured event after a workflow decision.

Use built-in CRM, Channels, Tables, or agent context first when they already provide the data.

Frontline Public API

Use the Frontline Public API when an integration needs programmatic access to assistants, flows/workflows, billing/usage, or analytics where supported.

This Academy page stays high-level and practical. For endpoints, parameters, authentication, and request examples, open the public Redocly reference: https://frontline-public-api.redocly.app/api.

Frontline CLI

If the integration work belongs in terminal scripts, use the public npm package @getfrontline/cli: https://www.npmjs.com/package/@getfrontline/cli/.

The CLI installs the frontline and max binaries for Public API commands, saved profiles, JSON-friendly output, and Max workflows.

How to choose

Use API Call or Outgoing Webhook when one workflow run needs to call or notify another system.

Use the Public API or CLI when an external system, script, or developer needs to operate on Frontline resources outside a single workflow execution.

Before you start

Confirm the external system owner, endpoint, method, authentication pattern, request payload, response fields, rate limits, timeout behavior, and fallback route.

Store credentials in the workspace-approved secret or variable mechanism. Public examples should use placeholders such as {{apiKey}} or {{externalRecordId}}.

Step-by-step implementation

Open Studio and the workflow that needs the integration.

Add or inspect an API Call or Outgoing Webhook node according to the direction of the integration.

Map workflow variables into request fields instead of hardcoding customer-specific values.

Map response fields into the next workflow step only after confirming the expected shape.

Add a failure branch for timeout, non-2xx response, missing field, revoked credential, or rate limit.

Run the workflow with a sample payload and inspect Logs before enabling broader traffic.

How to verify it worked

The sample run should show the request payload, sanitized response, branch decision, downstream action, and error handling in Logs.

A workflow that depends on an API is not launch-ready until the failure branch is as clear as the success branch.

Common mistakes

Do not hardcode tokens, API keys, bearer strings, customer IDs, or private URLs in workflow nodes or Academy examples.

Do not assume the external response always has the field you need.

Do not skip logs; integrations fail in ways operators need to see.

Troubleshooting

If the API call fails, check endpoint, method, auth variable, request body, timeout, and response code.

If the next node receives empty data, verify response mapping and field names in Logs.

If retries create duplicates, add idempotency or a lookup step before write actions.

Clear next step

Create one sample API run with placeholder values, verify success and failure logs, then document the credential owner before moving the workflow to Live.

Transcript

Open searchable transcript

Connect external systems to Frontline through safe API and webhook patterns with explicit payloads, variables, logs, fallbacks, and no hardcoded credentials. What you will build You will build a safe integration pattern that lets a workflow call an external system or send an outgoing webhook, then verify the response and route failures. The example should use placeholder endpoints and sample payloads only. Never place secrets or private URLs in public Academy content. When to use it Use API Call or Outgoing Webhook when Frontline needs information from an external system, must notify another tool, or should hand off a structured event after a workflow decision. Use built-in CRM, Channels, Tables, or agent context first when they already provide the data. Before you start Confirm the external system owner, endpoint, method, authentication pattern, request payload, response fields, rate limits, timeout behavior, and fallback route. Store credentials in the workspace-approved secret or variable mechanism. Public examples should use placeholders such as {{apiKey}} or {{externalRecordId}}. Step-by-step implementation Open Studio and the workflow that needs the integration. Add or inspect an API Call or Outgoing Webhook node according to the direction of the integration. Map workflow variables into request fields instead of hardcoding customer-specific values. Map response fields into the next workflow step only after confirming the expected shape. Add a failure branch for timeout, non-2xx response, missing field, revoked credential, or rate limit. Run the workflow with a sample payload and inspect Logs before enabling broader traffic. How to verify it worked The sample run should show the request payload, sanitized response, branch decision, downstream action, and error handling in Logs. A workflow that depends on an API is not launch-ready until the failure branch is as clear as the success branch. Common mistakes Do not hardcode tokens, API keys, bearer strings, customer IDs, or private URLs in workflow nodes or Academy examples. Do not assume the external response always has the field you need. Do not skip logs; integrations fail in ways operators need to see. Troubleshooting If the API call fails, check endpoint, method, auth variable, request body, timeout, and response code. If the next node receives empty data, verify response mapping and field names in Logs. If retries create duplicates, add idempotency or a lookup step before write actions. Related workflows Build a workflow to control when the integration runs and how errors route. Create a table when the integration needs local reference data for routing or mapping. Clear next step Create one sample API run with placeholder values, verify success and failure logs, then document the credential owner before moving the workflow to Live.

FAQs

Where should credentials live?

Use the workspace-approved secret or variable mechanism. Do not hardcode secrets in workflow nodes or Academy content.

Should I publish private URLs in docs?

No. Public Academy examples should use placeholders and sanitized endpoint descriptions only.

How do I make API workflows reliable?

Validate payloads, map responses explicitly, add failure branches, inspect logs, and avoid duplicate writes.