API Execution

By default, the Floe agent interacts with your product the same way a user does: clicking buttons, filling forms, navigating screens. API execution adds a second mode. When enabled, the agent can call your product's APIs directly to complete actions faster or handle workflows that are difficult to accomplish through the UI alone.

API execution is optional and off by default. Most teams never need it. This page covers when to enable it, how the safety controls work, and what changes in the agent's behavior at the execution layer.

Browser actions vs API actions

The agent has two ways to get things done in your product.

Browser actions are the default. The agent clicks, types, scrolls, and navigates just like a human user. It works within your existing UI, which means your product's own validation, permissions, and error handling apply automatically. If a button is disabled, the agent can't click it. If a form field rejects bad input, the agent sees the error and adjusts.

API actions bypass the UI entirely. The agent sends HTTP requests to your product's endpoints via browser automation. This is faster for bulk operations, programmatic workflows, or actions buried deep in nested menus. But it also means your UI-level guardrails don't apply. The safety controls described below replace them.

For most use cases during demos and onboarding, browser actions are all you need. The agent walks through your product the way a real user would, which is the whole point. API execution matters when the agent needs to do something that would take 30 clicks through the UI, like importing a batch of records or configuring a series of integrations.

When to enable API execution

Enable it when:

  • The agent needs to create sample data in bulk during demos (e.g., populating a dashboard with realistic records so the prospect sees value immediately)
  • Onboarding flows require backend setup that has no UI (e.g., provisioning API keys, creating webhook subscriptions)
  • Multi-step workflows are too slow through the browser (e.g., configuring 15 notification rules one at a time)

Leave it off when:

  • Your product's UI already covers everything the agent needs to do
  • You want the agent to demonstrate the actual user experience during demos, not a shortcut
  • You haven't mapped which endpoints are safe for automated access
  • You're still in the early stages of setup and want to keep things simple

Safety controls

API execution ships with three layers of protection. All are configured in the API Execution section of your site settings.

Per-endpoint enable/disable

Every API endpoint the agent discovers is listed individually. Each one has a toggle. Nothing is enabled by default. You choose exactly which endpoints the agent can call.

This is the most important control. If you enable API execution but only toggle on three endpoints, the agent can only call those three. Everything else stays browser-only.

Rate limiting

Set maximum calls per minute for each enabled endpoint. This prevents runaway loops where the agent retries a failing request or iterates too aggressively.

A reasonable starting point: 10 calls per minute for read endpoints, 5 per minute for write endpoints. Adjust based on your product's tolerance and what the agent needs to do during a typical session.

Dry-run mode

Dry-run mode lets the agent plan API calls without executing them. The agent goes through its normal decision process and logs what it would have called, with what parameters, but never sends the request.

Use dry-run mode to:

  • Audit what the agent wants to do before giving it live access
  • Debug unexpected behavior without risking data changes
  • Train your team on what API execution looks like before rolling it out

Once you're confident the agent's behavior matches your expectations, switch from dry-run to live execution.

Setting it up

  1. Go to your site in the Floe dashboard
  2. Open Settings then API Execution
  3. Toggle API execution on for the site
  4. Review the discovered endpoints
  5. Enable specific endpoints you want the agent to use
  6. Set rate limits for each enabled endpoint
  7. Start in dry-run mode, review the logs, then switch to live when ready

The agent discovers endpoints from your product during exploration and from your ingested content. If an endpoint is missing, re-running exploration or adding API documentation to your content sources usually picks it up.

How the agent decides which mode to use

When API execution is enabled, the agent evaluates each action and picks the best approach. For a demo where the goal is showing the user how the product works, it favors browser actions because the prospect needs to see the UI. For bulk setup during onboarding, it may use an API call if one is available and faster.

The agent never uses API execution for actions where showing the UI is the point. It uses its understanding of capabilities to decide whether the current moment calls for demonstrating or executing. See how it works for more on the agent's decision-making.

FAQ

Does enabling API execution require me to share API credentials? You provide the credentials in your site settings, encrypted at rest. The agent uses them only during active sessions and does not store them beyond the session context.

Can the agent call endpoints I haven't explicitly enabled? No. The per-endpoint toggle is a hard gate. Unenabled endpoints are inaccessible to the agent regardless of context.

What happens if an API call fails? The agent falls back to browser actions. If the endpoint returns an error, the agent attempts the same action through the UI. If both fail, it reports the issue in the session log and moves on.

Should I enable API execution for demos? Usually not. Demos benefit from showing the real UI experience. The exception is when you need realistic sample data in the product before the walkthrough begins, in which case API execution can set the stage quickly.