Send email from FlutterFlow
One API Call in FlutterFlow, with the key kept out of the app. Where to put it, what to test with, and why a mobile app should not hold the key at all.
Updated September 15, 2026
FlutterFlow can make HTTP requests from an action, and a Pigeon Atlas send is one POST with a JSON body. The setup is five minutes. The decision that matters is where the key lives, and for a mobile app the answer is "not in the app".
The API call
In the left bar, API Calls → Add API Call:
| Field | Value |
|---|---|
| API Call Name | Send email |
| Method | POST |
| API URL | https://pigeonatlas.com/v1/emails |
Under Headers, add two:
Authorization: Bearer [apiKey]
Content-Type: application/json
Under Variables, add apiKey, to, subject and body, all strings. Under Body, choose JSON and paste:
{
"from": "Your App <hello@mail.yourapp.com>",
"to": "<to>",
"subject": "<subject>",
"text": "<body>"
}
FlutterFlow substitutes <variable> inside the body and [variable] inside headers. Press Test API Call with your own address in to — it really sends — and confirm the response is {"id": "..."}. Add a JSON Path named id with path $.id so the message id is available to the action that called it.
Where the key should live
A key inside a mobile app is a key inside every copy of the app, and app bundles are trivially unpacked. Anyone who extracts it can send from your domain until you revoke it. FlutterFlow's own guidance is the same: Private API calls (in the API call's settings) route the request through FlutterFlow's proxy so the headers never ship in the bundle. Turn that on and put the real key there rather than in a variable the app fills in.
The stronger arrangement is not to send from the app at all. A Cloud Function or a Supabase Edge Function that the app calls — with the user's session, not with your key — decides whether a message should go, builds it, and sends it. The Supabase guide has that function; the app's API call then points at your function instead of at us, with no key in it.
Using the call
Add an action to a button or a page load: Backend/Database → API Call → Send email, fill to, subject and body from page state or the authenticated user, and branch on Succeeded to show confirmation. The id from the JSON path is what to store if you want to look the message up later.
Before it works
Add mail.yourapp.com in Pigeon Atlas and publish the DKIM, SPF and MX records it shows. The from address in the body must be on that domain; anything else is refused. Use a subdomain, never the bare domain — a sign-in code and a newsletter should not share a reputation.
A thousand a month free, no card
Enough to verify a domain and run a small app from it.