Connecting external services

How Floot apps talk to third-party APIs, webhooks, and email providers.

Floot apps can connect to almost any external service over its API. This page covers how that works, and where the edges are.

API integrations

Describe the integration you want and Floot builds it.

Works best with:

  • Well-documented APIs
  • APIs with clear authentication (API keys, OAuth)
  • Established APIs that have been around a while

For newer or niche APIs: if the documentation is online, Floot can research it. Otherwise, paste the relevant docs into the chat so Floot can learn the endpoints and data shapes.

Never paste API keys into the chat

Floot opens a secure dialog to collect keys and secrets. They are stored encrypted, injected into your backend at runtime, and never shown to the AI.

Example

Implement the product checkout flow using Stripe.

Floot will:

  1. Set up the API connection
  2. Ask for your API key in a secure dialog and store it safely
  3. Build the endpoints and screens your app needs

Webhooks

Webhooks let external services push data into your Floot app when something happens — a payment succeeds, a form is submitted, a delivery status changes.

  1. 1

    Ask Floot for an endpoint

    Create a webhook endpoint that handles payment events.
  2. 2

    Publish your app

    The webhook URL is a real, public URL on your published app.

  3. 3

    Register the URL with the service

    Paste it into the external service's webhook settings and send a test event.

Email

Floot apps can send and receive email with no third-party account — see What's built in. If you would rather use your own provider, Floot integrates with Resend, SendGrid, Mailgun, Postmark, Amazon SES, and Mailchimp:

Set up SendGrid to send welcome emails when users sign up.

Things to know

Floot backends are serverless, which shapes a few design decisions:

No local filesystem or in-memory state
Anything that has to survive between requests belongs in the database or in Floot Storage — not on disk or in a variable.
No always-on custom server process
Long-running or recurring work runs as a scheduled or background job instead of a daemon you keep alive.
Heavy scraping belongs elsewhere
For large-scale web scraping, use a dedicated service such as ScrapingBee and have your app call it.

Background work and realtime are supported

Scheduled jobs, background jobs, and WebSocket-based realtime used to be gaps. They are all built in now — see What's built in.