Zoho Mail

Open the Zoho API Console at api-console.zoho.com and sign in with your Zoho account. Click 'Add Client' and choose 'Self Client' — this is the correct type for server-to-server access where no user redirect is needed. Give it a name (e.g. 'FlutterFlow Mail Proxy') and click Create. Once created, go to the 'Generate Code' tab. In the Scope field, enter the two required scopes separated by a comma: `ZohoMail.accounts.READ,ZohoMail.messages.CREATE`. The READ scope allows fetching your accountId; CREATE scope allows sending. Set the time duration to the maximum available and click Create. Copy the grant code immediately — it expires in about a minute. Now switch to the 'Client Secret' tab and copy your Client ID and Client Secret. Then open a tool like Postman or curl to exchange the grant code for tokens. Make a POST to `https://accounts.zoho.com/oauth/v2/token` with these form fields: `code` (your grant code), `client_id`, `client_secret`, `redirect_uri` (use `https://www.zoho.com/crm/oauth` as a placeholder for self-clients), and `grant_type=authorization_code`. The response will include an `access_token` and a `refresh_token`. Copy the refresh token — this is your long-lived server secret. Store it in a secure place (Firebase project environment variables or Secret Manager), never in FlutterFlow or source code. Note your data center region: if your Zoho account is in the EU, your token URL is `accounts.zoho.eu` and your Mail API URL will be `mail.zoho.eu`.

Because the Zoho refresh token is a permanent server credential that must never ship inside a compiled Flutter app, you need a backend proxy to handle token minting. Firebase Cloud Functions is the recommended choice since it integrates well with Firebase Auth (which many FlutterFlow apps already use) and has a generous free tier for infrequent calls. In your Firebase project, enable Cloud Functions (Blaze plan required for outbound HTTP). Create or open your `functions/index.js` file. The function should do two things: first, store the refresh token as a Firebase environment variable or Secret Manager secret (never hardcode it in the function source); second, expose an HTTPS endpoint that FlutterFlow can call to get a fresh access token. Deploy this function using the Firebase CLI (`firebase deploy --only functions`). Once deployed, Firebase gives you an HTTPS URL like `https://us-central1-yourproject.cloudfunctions.net/getZohoMailToken`. This is the only URL you'll put into FlutterFlow — not the Zoho token URL, and not the Zoho Mail API with the code in it. Test the function in your browser or Postman to confirm it returns a valid `access_token` string before moving to FlutterFlow.

1// functions/index.js
2const functions = require('firebase-functions');
3const axios = require('axios');
4
5// Store these in Firebase environment config or Secret Manager
6// firebase functions:config:set zoho.refresh_token=... zoho.client_id=... zoho.client_secret=... zoho.region=com
7exports.getZohoMailToken = functions.https.onRequest(async (req, res) => {
8  // Allow FlutterFlow web builds (CORS)
9  res.set('Access-Control-Allow-Origin', '*');
10  if (req.method === 'OPTIONS') {
11    res.set('Access-Control-Allow-Methods', 'GET, POST');
12    res.set('Access-Control-Allow-Headers', 'Content-Type');
13    return res.status(204).send('');
14  }
15
16  const config = functions.config().zoho;
17  const region = config.region || 'com'; // 'com' for US, 'eu' for EU
18
19  try {
20    const params = new URLSearchParams({
21      grant_type: 'refresh_token',
22      refresh_token: config.refresh_token,
23      client_id: config.client_id,
24      client_secret: config.client_secret,
25    });
26
27    const response = await axios.post(
28      `https://accounts.zoho.${region}/oauth/v2/token`,
29      params.toString(),
30      { headers: { 'Content-Type': 'application/x-www-form-urlencoded' } }
31    );
32
33    const accessToken = response.data.access_token;
34    if (!accessToken) {
35      return res.status(500).json({ error: 'No access token returned', details: response.data });
36    }
37
38    return res.status(200).json({ access_token: accessToken });
39  } catch (err) {
40    console.error('Token refresh failed:', err.response?.data || err.message);
41    return res.status(500).json({ error: 'Token refresh failed' });
42  }
43});
44

In FlutterFlow, click 'API Calls' in the left navigation sidebar. Click the '+' button (or '+ Add') and select 'Create API Group'. Name it something clear like 'Zoho Mail' and set the base URL to your mail region — for US accounts this is `https://mail.zoho.com/api` and for EU accounts `https://mail.zoho.eu/api`. Important: do NOT use zohoapis.com here — that domain is for Zoho CRM and Books, not Zoho Mail. Using the wrong domain will produce 404 errors on every call. With the API Group created, you now need two API Calls inside it. Click '+ Add' inside the Zoho Mail group to create the first call. Name it 'Get Accounts' and set the method to GET with the path `/accounts`. This endpoint returns the list of mail accounts associated with your Zoho login. You'll call this once on app start to get the numeric accountId needed for sending. Create a second API Call named 'Send Message', set method to POST, and path to `/accounts/[accountId]/messages` — you'll replace `[accountId]` with a Variable in a moment. Go to the Variables tab for this call and add a variable named `accountId` (String). Then update the path to use this variable: `/accounts/{{accountId}}/messages`. Add two more variables: `toAddress` (String), `subject` (String), and `content` (String). For the body of the Send Message call, switch to the Body tab, select JSON, and enter a template with your variables referenced using double curly brace syntax. For the Authorization header, do NOT add it to the API Group shared headers yet — you'll handle it dynamically per call using an App State variable. Go back to the API Group settings and add a shared header: `Content-Type` with value `application/json`. Do not add the Authorization header with a hardcoded token here.

1{
2  "Get Accounts": {
3    "method": "GET",
4    "path": "/accounts",
5    "headers": {
6      "Authorization": "Zoho-oauthtoken {{accessToken}}"
7    }
8  },
9  "Send Message": {
10    "method": "POST",
11    "path": "/accounts/{{accountId}}/messages",
12    "headers": {
13      "Authorization": "Zoho-oauthtoken {{accessToken}}"
14    },
15    "body": {
16      "fromAddress": "yourname@yourdomain.com",
17      "toAddress": "{{toAddress}}",
18      "subject": "{{subject}}",
19      "content": "{{content}}"
20    }
21  }
22}
23

With the API Group set up, you need to wire the token-fetching flow so your app always has a valid access token and accountId before it tries to send email. The right place to do this is in the app's initial action — either on the Main page's On Page Load action, or in your app's first authenticated screen. First, create two App State variables. Go to App Values in the left sidebar, then App State, and add: `zohoAccessToken` (String, default empty) and `zohoAccountId` (String, default empty). These will hold the values once fetched. Next, create a separate FlutterFlow API Call (not in the Zoho Mail group) that calls your Firebase Cloud Function URL. This is a GET call to your deployed function URL, e.g., `https://us-central1-yourproject.cloudfunctions.net/getZohoMailToken`. It returns `{"access_token": "..."}`. In the Response & Test tab, paste a sample response and generate JSON paths. The path `$.access_token` should auto-generate. This is not Zoho's API — it's your own proxy, so it can use any auth scheme you want (or none, since Firebase can validate the caller via App Check). On your app's entry screen, open the Action Flow Editor (click the screen → Actions panel → + Add Action → Backend/API Calls → API Request). Chain two actions: first, call 'Get Token' (your Cloud Function call) and update App State `zohoAccessToken` with `$.access_token`. Second, immediately after, call 'Get Accounts' (the Zoho Mail API Call), passing `{{zohoAccessToken}}` as the `accessToken` variable. Parse the response JSON Path `$.data[0].accountId` and update App State `zohoAccountId` with the result. This two-step chain runs once when the app loads, giving you both the token and the accountId stored in App State, ready to use in any send action.

Now build the UI for sending an email. For a confirmation email after a form submission, you typically already have the recipient's email address from a TextFormField and the subject/content can be partially templated. Create a form page or add a form to an existing screen. You need at minimum a TextFormField for the recipient address and whatever input fields drive the email content. Add a Button widget at the bottom of the form (e.g., 'Send Confirmation' or 'Submit'). Open the Action Flow Editor for this button. Add an action: Backend/API Calls → API Request → select your 'Zoho Mail' group → 'Send Message'. You'll now map each variable: - `accessToken` → App State → `zohoAccessToken` - `accountId` → App State → `zohoAccountId` - `toAddress` → the TextFormField value for recipient email - `subject` → a string literal like 'Your booking is confirmed' or a template using other form values - `content` → a multi-line string built from your form fields (name, date, time, etc.) After the Send Message action, add a Show Snack Bar action with a success message like 'Email sent successfully!' For error handling, use an If/Else conditional checking the API response status code: if it is not 200/201, show an error snack bar. If your app sends emails frequently (more than roughly every 2 seconds sustained), be aware that Zoho Mail's API has a rate limit of approximately 30 requests per minute before triggering a temporary lock. For single-send use cases like form confirmations, this limit is very unlikely to be hit. If you build a bulk-send feature, add a delay between sends. For the `fromAddress` field in the API body, use the email address associated with your Zoho Mail account. You can also make this a FlutterFlow App Constant (App Values → App Constants) so it's set once rather than repeated in every action.

Zoho access tokens expire after 3,600 seconds (one hour). In a typical mobile app where users open the app, perform a task, and close it, this is rarely an issue — the token fetched on launch is still valid for the entire session. However, if your app has long-lived sessions or background processes, you need to handle 401 responses gracefully. In the Action Flow Editor, after each Zoho Mail API Call, add a conditional action that checks the HTTP response code. Use the API response's `statusCode` output variable. If `statusCode == 401`, fire a second chain: call your Cloud Function again to get a fresh token, update App State `zohoAccessToken`, then retry the original action. This creates a clean refresh-then-retry pattern without bothering the user. For the rate limit, Zoho Mail allows approximately 30 API requests per minute. The API returns a 4xx or a temporary lock response when this is exceeded. For normal usage — one email per user action — you'll never approach this limit. If you're building a feature that could trigger multiple sends quickly (e.g., a 'resend' button a user might tap repeatedly), disable the button for a few seconds after each tap using a local page state variable toggled by a Timer action. Also note that Zoho Mail has per-day sending limits that vary by plan. The free tier (up to 5 users) has lower daily limits than Mail Lite and higher plans — check your current plan's limits in your Zoho Mail admin dashboard. These per-day limits apply to actual email messages sent, not API calls generally. For EU accounts specifically, double-check that both your token URL and your API base URL use the `.eu` suffix. Mixing account domain (`accounts.zoho.com`) with the EU API domain (`mail.zoho.eu`) causes 401 errors that are hard to diagnose. The Cloud Function should be configured with the correct region from the start.