Connect your App to other services

What connecting a service does

Your App can reach out to the outside world — add a row to a sheet, book a calendar slot, send a text message, call another company's API — once you connect that service. You connect each service once, and its credential is kept, encrypted, in your account's vault. From then on your App's code calls the service without ever touching the raw key: the credential is added on the server when your App runs, so it stays out of your App's pages and out of anything a visitor could see.

Open your App in the editor, choose the Equip tab, then Connect. The page has three parts:

• Services — the services your App can work with, sorted by what they are for: Sheets, Calendar, Files, Docs, Slides, Maps, GitHub, Zapier / Make and Bank accounts. Each says whether it is connected, and to whom.
• Custom — connections to any other service, set up by the building assistant.
• Variables — everything your App's code reads that isn't code: plain values, and the keys, connected accounts and data links it reads from your vault. Everyone building the App sees this list; only you, the owner, choose what each one reads.

Texts, Slack and the account your App sends email through are connected from Messages on the same tab, because they are ways your App reaches people. Your own Stripe keys are set in Manage › Payments.

Every connection is your Live App's, as Works on says — and your Draft uses the same one, so a connection works in your Draft the moment you set it up and you never re-enter a key to test. It also means a Draft calls the same real account your published App does: when you are testing something that sends, charges or writes for real, use a test account at the service itself.

Services and Custom belong to your published App. Until your first publish they are empty, and pressing a Settings icon opens Publish first, which takes you to Publish on the Manage tab. Variables does not wait: you can set up every key an App needs before it has ever been published.

Connect a service

In Equip › Connect, select the Settings icon beside a service under Services. Its window shows:

• Provider — for a service two companies offer, which one: Google or Microsoft for Sheets, Calendar and Files. A service shows the one it is connected with first.
• How it connects, which depends on the provider:
  • Sign-in — for Google and Microsoft services, Connect opens the provider's sign-in in a new window. Once you have signed in, the service reads Connected with the account beside it, and the account is kept in your account's vault, where your other Apps can use it too. Reconnect signs in again. Disconnect takes the account off this App only — it stays in your vault for your other Apps. If your browser blocks the window, the page says the Sign-in window was Blocked: Allow pop-ups for the editor, then select Try again. If the sign-in itself fails, the reason is shown on screen and stays there until your next press.
  • Key — for Maps and GitHub, paste the key the service gives you and select Connect; Update replaces it later, and Remove takes it off this App. The box always starts empty: a key is never shown again once saved.
  • A key with its account details — for Bank accounts: fill in the Client ID, pick the Environment — Sandbox · test banks, chosen for you, or Production · real banks — and paste that environment's secret as the Key; then select Connect. The client ID and the environment read back when you reopen the window, the key never does.
  • One press — Zapier / Make needs Nothing to paste and No sign-in: select Connect.
• Adds — how many ready-made actions connecting it gives your App's actions. Select the count to see their names. No page can run them until you open one.
• Limits — a limit worth knowing before you connect: Drive · only files it made.
• What it costs, and Works on.

Connecting a service also adds the variable its code reads to Variables, and disconnecting the service is what takes that variable away.

Connecting, updating and disconnecting are the owner's. A collaborator sees which account each service is connected with, and nothing to press.

One connected account for all your Apps

Keys and connected accounts belong to your MotherFluxer account, not to one App. When you sign in to a Google account for one App's Sheets, that account is kept once, in Settings › Account › Connections & Keys. Connecting the same Google account from another App — or from account settings — uses that same entry rather than making a second one.

So one Google account used by three Apps is one entry, and reconnecting it once, from any of them, updates all three.

Taking a connection off one App only stops that App using it: the account stays in your vault and your other Apps keep working. To be rid of an account for good, Revoke it from each App that reads it in Connections & Keys, then select Remove there. Removing a Google account also ends MotherFluxer's access to it at Google.

One account per service

An App holds one account per service. Connecting the same service a second time — a different workspace, a different account, or simply a fresh key for the one you already use — replaces the account your App uses now.

MotherFluxer will not do that quietly. When you connect a service your App already has, it stops and asks first — This app is already connected — naming the service and, where it knows it, the account you are connected as. Choose Replace the connection to go ahead, or cancel and nothing changes. For a service you connect by signing in, the question comes before the sign-in window opens, so you are never asked to sign in and then told no.

Replacing a key on the same account looks exactly like switching to a different account — the stored key carries no record of whose it is — so a routine key rotation takes the same one-click confirmation. It is one extra click, and it is what stops a second connection silently knocking out a working one.

A connect that fails partway leaves nothing behind that claims the account, so trying again goes straight through — you are never asked to replace a connection that never finished.

Connect Google Sheets

With Google Sheets connected, your App works in the spreadsheets of the Google account you connect: it can add rows, read, update and clear ranges, create spreadsheets and sheets, and format, sort, filter and chart them.

1. In Equip › Connect, select the Settings icon on Sheets, and pick Google under Provider.
2. Select Connect. Google's sign-in opens in a new window; if your browser blocks it, Allow pop-ups for the editor and select Try again.
3. Sign in to the Google account whose spreadsheets your App should use. Google may first warn that it hasn't verified the app; its link to go on to motherfluxer.ai continues.
4. Google lists the access your App is asking for. Select "Continue".

Sheets then reads Connected, with the account beside it. There is nothing to set up at Google beyond the account itself. Signing in again to an account you have already granted takes you straight to Google's "You're signing back in" screen.

Connect Microsoft Excel

With Microsoft Excel connected, your App works in the Excel workbooks kept in the connected account's OneDrive — personal or work — or in SharePoint: it can list worksheets, read and write ranges and formulas, add tables and rows, and add charts.

1. In Equip › Connect, select the Settings icon on Sheets, and pick Microsoft under Provider.
2. Select Connect. Microsoft's sign-in opens in a new window; if your browser blocks it, Allow pop-ups for the editor and select Try again.
3. Sign in to the Microsoft account — a personal outlook.com account works. Microsoft asks "Let this app access your info?", marks the app as unverified, and names the access asked for. Select "Accept".

There is nothing to set up at Microsoft beyond the account. Connect one Microsoft service at a time: two Microsoft sign-in windows open at once share one sign-in, and only the newest one's "Accept" goes through. If the account has already granted other Microsoft services to MotherFluxer, Microsoft's screen lists those too — connecting Excel asks only for Excel's own access.

Connect Google Calendar

With Google Calendar connected, your App works in the connected account's calendars: it can list calendars and events, create, change and delete events, add one from a line of text, and check when people are free or busy — for bookings, schedules and reminders.

1. In Equip › Connect, select the Settings icon on Calendar, and pick Google under Provider.
2. Select Connect. Google's sign-in opens in a new window; if your browser blocks it, Allow pop-ups for the editor and select Try again.
3. Sign in to the Google account whose calendar your App should use. Google may first warn that it hasn't verified the app; its link to go on to motherfluxer.ai continues.
4. Google lists the access your App is asking for. Select "Continue".

There is nothing to set up at Google beyond the account itself. Calendar can hold a Google and a Microsoft calendar side by side: picking a Provider only changes which one the window shows.

Connect Microsoft Calendar

With Microsoft Calendar connected, your App works in a Microsoft 365 or Outlook calendar: it can list, create, change and delete events, Teams online meetings included, and find times when everyone is free.

1. In Equip › Connect, select the Settings icon on Calendar, and pick Microsoft under Provider. A Google calendar already connected stays connected — the Provider switch only changes which one the window shows.
2. Select Connect. Microsoft's sign-in opens in a new window; if your browser blocks it, Allow pop-ups for the editor and select Try again.
3. Sign in to the Microsoft account — a personal outlook.com account works. Microsoft asks "Let this app access your info?", marks the app as unverified, and names the access asked for. Select "Accept".

There is nothing to set up at Microsoft beyond the account. Connect one Microsoft service at a time: two Microsoft sign-in windows open at once share one sign-in, and only the newest one's "Accept" goes through.

Connect Google Drive

With Google Drive connected, your App manages the files it creates in the connected account's Drive: it can list them, upload text or any other file, make folders, and export, copy, share, move, download, trash and delete them. It sees only the files it made itself — the window's Limits says so, Drive · only files it made — so the rest of your Drive stays out of its reach.

1. In Equip › Connect, select the Settings icon on Files, and pick Google under Provider.
2. Select Connect. Google's sign-in opens in a new window; if your browser blocks it, Allow pop-ups for the editor and select Try again.
3. Sign in to the Google account whose Drive your App should use. Google may first warn that it hasn't verified the app; its link to go on to motherfluxer.ai continues.
4. Google lists the access your App is asking for. Select "Continue".

There is nothing to set up at Google beyond the account itself.

Connect Microsoft OneDrive

With Microsoft OneDrive connected, your App works in the connected account's OneDrive: it can list and search files, upload text or any other file, make folders, share files and download them.

1. In Equip › Connect, select the Settings icon on Files, and pick Microsoft under Provider.
2. Select Connect. Microsoft's sign-in opens in a new window; if your browser blocks it, Allow pop-ups for the editor and select Try again.
3. Sign in to the Microsoft account — a personal outlook.com account works. Microsoft asks "Let this app access your info?", marks the app as unverified, and names the access asked for. Select "Accept".

There is nothing to set up at Microsoft beyond the account. Connect one Microsoft service at a time: two Microsoft sign-in windows open at once share one sign-in, and only the newest one's "Accept" goes through.

Connect Google Docs

With Google Docs connected, your App can create documents in the connected Google account, read them, and edit them — text, formatting, tables, and pictures from a web address.

1. In Equip › Connect, select the Settings icon on Docs, then select Connect. Google's sign-in opens in a new window; if your browser blocks it, Allow pop-ups for the editor and select Try again.
2. Sign in to the Google account your App should write in. Google may first warn that it hasn't verified the app; its link to go on to motherfluxer.ai continues.
3. Google lists the access your App is asking for. Select "Continue".

There is nothing to set up at Google beyond the account itself.

Connect Google Slides

With Google Slides connected, your App can create presentations in the connected Google account, read them, and edit them — slides, shapes, text, and pictures from a web address.

1. In Equip › Connect, select the Settings icon on Slides, then select Connect. Google's sign-in opens in a new window; if your browser blocks it, Allow pop-ups for the editor and select Try again.
2. Sign in to the Google account your App should write in. Google may first warn that it hasn't verified the app; its link to go on to motherfluxer.ai continues.
3. Google lists the access your App is asking for. Select "Continue".

There is nothing to set up at Google beyond the account itself.

Connect Google Maps

With Google Maps connected, your App can search for places by name, turn an address into coordinates and back, and work out routes. It uses a key from your own Google Cloud project, and Google bills those calls to that project.

At Google:

1. In the Google Cloud console, create a project for the key — one of its own, apart from projects that hold anything else — and link a billing account to it. A new Google account's free trial stops the project's services when the trial ends, unless you upgrade the billing account.
2. Under APIs & Services → Library, enable Places API (New), Geocoding API and Routes API. Enabling the first one opens Google's Maps setup, which makes a key for you and offers to limit where it can be used from — choose "Maybe later": your App calls Google from MotherFluxer's servers, so a website or IP limit doesn't fit.
3. Under Credentials, open that key. Under API restrictions, tick only those three APIs, select "OK" inside the list — closing it any other way drops the change — and save. Then show the key and copy it.

In the editor:

4. In Equip › Connect, select the Settings icon on Maps, paste the key as the Key, and select Connect. Update replaces it later, and Remove takes it off this App.

Connect GitHub

With GitHub connected, your App works in GitHub through a token you make there: it can list and create repositories, read and write files, list and open issues and pull requests, comment on issues, list commits, start a workflow, and publish releases with their files. This is a different link from backing your App's own code up to GitHub, which you set up from the App's File menu.

At GitHub:

1. Open Settings → Developer settings → Personal access tokens → Fine-grained tokens, and select "Generate new token". A classic token works too.
2. Give it a name, choose its resource owner, an expiration, and which repositories it may reach.
3. Under permissions, give Contents read and write for files; add Issues and Pull requests if your App reads or opens them. GitHub refuses an action the token has no permission for.
4. Generate the token and copy it — GitHub shows it only once.

In the editor:

5. In Equip › Connect, select the Settings icon on GitHub, paste the token as the Key, and select Connect. When the token expires, make a new one and paste it with Update.

Connect bank accounts with Plaid

With Bank accounts connected, a visitor can link a bank or card through Plaid on your App's page, and your App reads that account's transactions once, then lets go of the link — nothing is kept that could read the account again. It runs through your own Plaid account.

At Plaid:

1. Sign in to the Plaid Dashboard; signing up makes you a team.
2. Open its Keys page. It shows your Client ID — one for the team, used with every environment — and a secret for each environment: the Sandbox secret, behind its eye icon, and the Production secret, which appears once Plaid has approved your team for real banks.
3. Build against Sandbox first. Plaid's test banks sign in with the username user_good and the password pass_good.

In the editor:

4. In Equip › Connect, select the Settings icon on Bank accounts. Fill in the Client ID, pick the Environment — Sandbox · test banks, chosen for you, or Production · real banks — and paste that environment's secret as the Key. Select Connect.
5. Connecting Adds two ready-made actions: one starts Plaid's bank sign-in on your page, the other reads the linked account's transactions. They start on Only this app, like every ready-made action; they are made to be opened to a page, so open them under Who can run it in Equip › Automations — the window names what each one reaches before it opens.

The client ID and the environment read back when you reopen the window; the key never does. To move from test banks to real ones, connect again with Production · real banks and its own secret — your App's code stays the same. Reading a real bank goes through your own account, so Plaid bills you for it.

Trigger automations with Zapier or Make

To have your App kick off a workflow you build in Zapier or Make — add a row to a sheet, post to a channel, start any automation there — connect Zapier / Make in Equip › Connect. There is nothing to paste and no sign-in: open its Settings and select Connect.

Then make a webhook in the automation tool and copy its address:

• In Make, create a scenario, add the Webhooks module, choose "Custom webhook", select "Add" and copy the address it gives you. Switch the scenario on — Make runs nothing sent to a scenario that is switched off. Make's Webhooks page lists every hook with its address and an on/off switch.
• In Zapier, start a Zap with Webhooks by Zapier and its "Catch Hook" trigger, and copy the address.

Your App's code sends to that address through the connection's action, with whatever fields you want the automation to receive, and the automation tool takes it from there.

One connection serves both tools, and Make's webhook addresses work whichever region your Make account is in. Worth knowing before you pick: Make hands out webhook addresses on its free plan, while Zapier keeps them behind a paid plan.

Send email through Gmail

Connect a Gmail account and the emails your App sends — welcome notes, receipts, its automatic emails — go out from that account.

1. In Equip › Messages, select the Settings icon on Email.
2. Under Gmail, select Connect. Google's sign-in opens in a new window; if your browser blocks it, Allow pop-ups for the editor and select Try again.
3. Sign in to the Gmail account to send from. Google may first warn that it hasn't verified the app; its link to go on to motherfluxer.ai continues.
4. Google lists the access your App is asking for — sending email as you. Select "Continue".

Email on the Messages page then reads Connected with Gmail and the account. There is nothing to set up at Google beyond the account itself. Gmail adds no ready-made actions — it is the account your App's emails are sent through, and they always go out from it, whatever From address an email names.

Send email through Outlook

Connect an Outlook or Microsoft 365 account and the emails your App sends go out from it. Outlook also Adds ready-made actions that read and manage that mailbox: list, search and read messages, reply, write and send drafts, move and flag messages, and list attachments. They start on Only this app — they act on your own mailbox, so no page can run them.

1. In Equip › Messages, select the Settings icon on Email.
2. Under Outlook, select Connect. Microsoft's sign-in opens in a new window; if your browser blocks it, Allow pop-ups for the editor and select Try again.
3. Sign in to the Microsoft account — a personal outlook.com account works. Microsoft asks "Let this app access your info?", marks the app as unverified, and names the access asked for. Select "Accept".

There is nothing to set up at Microsoft beyond the account. Connect one Microsoft service at a time: two Microsoft sign-in windows open at once share one sign-in, and only the newest one's "Accept" goes through.

Send email through SMTP (any mailbox)

SMTP (any mailbox) sends your App's email through almost any mailbox — Yahoo, iCloud, a company mail server, or Gmail with an app password — using that mailbox's own mail-server settings.

At your mail provider, find its SMTP settings — a host and a port — and, where it offers one, make an app password to use instead of the mailbox's own. For Gmail:

1. In your Google Account, open Security and turn on 2-Step Verification.
2. Open App passwords — Google asks you to confirm it's you first — type a name for it and select "Create".
3. Copy the 16-character password; Google shows it only once. Gmail's host is smtp.gmail.com and its port is 587.

In the editor, in Equip › Messages, select the Settings icon on Email. Under SMTP (any mailbox), fill in the Host, Port, Username and Password, and optionally From — left empty, it is the username — then select Connect. The settings read back when you reopen the window; the password never does, so you type it again to change anything, and Update saves the change.

Send email through SendGrid

SendGrid sends your App's email through your own SendGrid account, and Adds ready-made actions for templated email, marketing contacts and lists, suppressions and sending statistics.

At SendGrid:

1. Verify the address you will send from: Settings → Sender Authentication, verify a single sender (or your whole domain), and confirm the email SendGrid sends you. SendGrid refuses an email whose From address it hasn't verified.
2. Make a key: Settings → API Keys → "Create API Key". Restricted access with Mail Send set to full access is enough to send; the contacts, lists and statistics actions need those permissions too.
3. Copy the key — it starts with SG., and SendGrid shows it only once.

In the editor, in Equip › Messages, select the Settings icon on Email. Under SendGrid, paste the key as the Key and select Connect. Update replaces it later.

Send text messages

To have your App send text messages, connect a texting account from Equip › Messages:

1. On the Messages page, select the Settings icon on Texts.
2. Fill in the Account (the Account SID, which starts with AC) and the Key (your auth token), both from your own Twilio console.
3. Select Connect. Texts then reads Connected; Remove in the same window disconnects it.

Both values are in the Twilio Console: open the account menu → API keys & tokens → Auth Tokens. It shows your live credentials — the Account SID and its Auth token, behind an eye icon — beside a pair of test credentials. The live pair texts real phones, and Twilio charges for every message. The test pair is accepted the same way but sends and charges nothing, and takes only Twilio's own test sender number, +15005550006. Your Draft and your Live App use the same connection, so connect the live pair before visitors rely on your texts.

Connecting Adds an action your App's other actions call with the phone number to text, the message, and the Twilio phone number (or Messaging Service) it comes from. It is good for order confirmations, alerts and verification texts. Messages go through your own account, so the texting service bills you for them, and it Works on your Live App.

Post to Slack

To have your App post to Slack, connect it from Equip › Messages: select the Settings icon on Slack, paste your Slack app's bot token (it starts with xoxb-) as the Key, and select Connect.

The token comes from a Slack app you make for your workspace:

1. At api.slack.com/apps, select "Create New App", choose "From scratch", and give it a name and your workspace.
2. On the app's OAuth & Permissions page, under Bot Token Scopes, add chat:write to post, plus the scope each other action needs — reading channels, uploading files and so on. Install the app to your workspace and allow it.
3. Copy the Bot User OAuth Token, which starts with xoxb-.
4. In Slack, invite the bot to each channel it should post to.

Slack refuses an action whose scope the bot lacks until you add that scope and install the app again.

Connecting Adds ready-made actions your App's other actions call to post and read messages. Select the count in the window to see their names. Remove in the same window disconnects it.

Use your own Stripe keys

Stripe is not on Equip › Connect: your App's own Stripe account is set in Manage › Payments, and Stripe's ready-made actions — checkout, customers, subscriptions, invoices, refunds, products, prices and payment links — read that same key when the building assistant adds them. To charge on your own Stripe account, with no platform fee:

1. In the Stripe Dashboard, copy your Secret key from the "For developers" card on the Home page. A sandbox or test-mode key (it starts with sk_test_) charges no real cards while you build; a live key starts with sk_live_.
2. In Manage › Payments, select Settings on Account, set Charges to Own Stripe, and paste the Secret key.
3. Copy the address the window shows beside Webhook. In Stripe, open Workbench from the Developers bar at the bottom of the Dashboard, then Webhooks → "Add endpoint": paste the address, and pick the events the window lists beside Events. Until your App is first published, Webhook says After the first publish — it has no address yet.
4. Copy the new endpoint's signing secret (it starts with whsec_), paste it as the Signing secret, and select Save.

Connect any service with an API

Beyond the services listed in Equip › Connect, your App can connect to almost any service that offers an API. Ask the building assistant for it in plain language — "connect my CRM's API" — and it sets up the connection, which appears under Custom. A connection made with a key is tried against the service before it is added, so one that doesn't work never lands.

How you authorise it depends on the service:

• A key — give the building assistant the service's key, or add it yourself first with Add a key on Variables in Equip › Connect and tell the assistant the variable's name. Either way the key goes into your vault and never reaches your App's pages.
• Sign in with the service — for a service that only offers a "Sign in with…" style authorisation, first create an app in that service's developer settings. The building assistant tells you the exact redirect address that app must list, then asks for its client ID and client secret. The connection appears under Custom reading Off; open its Settings and select Connect to sign in. MotherFluxer keeps the access fresh, so your App keeps working without you signing in again.

A custom connection's window shows whether it is connected, what it Adds, and a Disconnect button.

Storing a service's key, or the client ID and client secret of your own sign-in app, is the App owner's. When a collaborator asks the building assistant to connect a service that needs one, the assistant doesn't store it — it tells them to ask you to connect it.

Your App's variables

Everything your App's code reads that isn't code — a key, a connected account, a site name, a list in another of your Apps — is a variable, declared once in your App's settings and listed under Variables in Equip › Connect. Each one has a name, what it is For, and one of two kinds of value:

• A plain value, written into the App itself — a region, a feature switch, a public map id. Its row shows the value. A name that starts with PUBLIC_ is one your App's pages may read too; every other plain value is read by your actions alone.
• A vault variable — a key, a connected account or a data link — whose value never lives in any of the App's files. It reads an entry in your account's vault, and its row says which: the key's name, the account it is connected as, or Setup needed while nothing is set. A vault variable can never be PUBLIC_, so it never reaches a page.

Plain values are usually added by the building assistant as it writes the code that reads them. You add a key or a data link yourself with Add a key (the + icon), and a connection you set up adds the variable its own code reads. The rows that still need setting up come first.

Under the list, the part says how every key is handled:

• Kept — Encrypted, Never shown again, and it Never reaches the page.
• Used by — Actions · as a header, and Signing and checking incoming messages.
• In code — the calls an action reads a key through: ctx.env.NAME, ctx.crypto.hmac and ctx.webhooks.verify.

The keys themselves are your account's: Settings › Account › Connections & Keys lists every one, with the Apps that read it. A collaborator sees each variable's name and whether it is set — Set by the owner, or Setup needed — never what it is for, or which key or account it reads; what a key is for shows only in your own setup window, to whoever must supply it.

Add a key or a data link

In Equip › Connect, select Add a key (the + icon on Variables). The New variable window asks for:

• Kind — Key, a value you paste once, or Data link, a list in another of your Apps.
• Name — what the code reads it as, such as MAPS_KEY.
• For — what it is for, in a few words, such as "Takes payments". This is what Setup needed shows whoever has to supply it next.
• For a key, its Value; then select Add. Adding a key under a name your App already reads replaces that key's value (Same name · Replaces the value) — and because it is one key, every other App of yours that reads it gets the new value too.
• For a data link, its Access — Read, or Read and write — and the list, picked from your Apps' lists; then select Link a list.

One press declares the variable in your App and puts its value in your vault. A variable added here is one your App needs, so a Live publish waits until it is set.

A data link lets this App's actions read — or read and write — a list in another of your Apps. The records stay in that App, under that list's own rules: nothing is copied. A list that holds people's details can be linked for reading only — writing is refused with Holds people’s details, so another App may only read it. The other App's lists show which of your Apps they are shared with.

Choose what a variable reads

As the owner, select a vault variable's row under Variables in Equip › Connect to open its window. It says what the variable is For and what it Reads now, and offers:

• From your vault — the entries in your account that fit it: keys for a key, data links for a data link, and for a connection's variable only that service's accounts. Select one and the variable reads it (Set). When none fits, it says Nothing in your vault fits.
• A new one, of the variable's kind: paste a New key and select Add; select Connect and the service's name to sign in to an account, which lands in your vault and is this App's at once; or link a list.
• Stop using — this App stops reading the key. It asks first: the Key Stays in your vault for your other Apps, while the Actions using it Stop working. A connection's own variable has no Stop using; disconnect the connection instead.

Picking an entry you set up for another App, or in account settings, is how one key serves several Apps without being pasted twice.

Setup needed

A variable your App needs that has nothing to read shows Setup needed, and those rows lead the Variables list in Equip › Connect.

• When you open an App that has one, the editor lands on Equip › Connect once, so the first thing you see is what is missing. A copy you saved from Slop opens this way: a copy carries the App's variables but none of the keys.
• The Publish review names each missing one under Setup needed and holds the publish; Set them up takes you to the list. Live won't publish while one is missing, and says which.
• Setting a variable up never waits for a publish — it works on an App that has never been published.

A collaborator sees Setup needed too, but setting it is the owner's.

A key typed into a file is refused

A key's value has one home: your vault. If you type or paste a secret's value — an API key, a token, a password inside a database address — into any of your App's files, the save is refused with A key can't be saved in a file. The notice names the file and the variable the value should become, and how the code reads that variable instead.

As the owner you get Declare and vault it. It opens the window for adding that key, already named: say what it is For, paste the Value and select Add, and one press declares the variable and stores the value. Then take the value out of the file and have the code read the variable. Until the value leaves the file, every save is refused; a collaborator is told the same and asks you to add the key.

A value meant to be public is not refused — a Zapier or Make webhook address, for one, belongs in the code.

The building assistant keeps the same rule: it never writes a key's value into a file, and it never reads or writes the files whose names start with a dot.

How your App's code uses a key or a connection

Your App's actions read a variable as ctx.env.NAME. A plain variable reads as its value. A vault variable reads as a sealed handle, never the key itself: pass it as a header to ctx.fetch, the helper that calls an outside API for your App, and the key is added on the server at the moment the call runs.

const resp = await ctx.fetch('https://api.example.com/v1/places', {
  method: 'POST',
  headers: { Authorization: ctx.env.MAPS_KEY },
  body: JSON.stringify({ query: input.place }),
});

Any action that uses your App can read every variable the App declares — there is no list of keys to keep per action. Reading a name the App doesn't declare stops the action with a message saying where to declare it. A self-contained or on-device action is given none of your keys.

A page reads only the PUBLIC_ variables, as window.env:

document.title = window.env.PUBLIC_SITE_NAME;

A connected service is reached through its ready-made actions, or through ctx.fetch with the variable the connection added. In every case the credential stays on the server, so nothing sensitive reaches the visitor's browser.

A connection's ready-made actions start on Only this app: your schedules, webhooks and other actions can run them, and a page can't. They act on your own account and take whatever they are sent, so an open one could let a visitor read your inbox, send as you or spend your money. To let a page reach a service, write your own action that decides what to send and where, and open that one under Who can run it. Connecting a service again keeps what you chose.

Ask the building assistant to connect something

You don't have to wire connections up by hand. Tell the building assistant what you want in plain language — "let my App text me when someone submits the form" or "connect my CRM's API" — and it sets up the connection, the variables it needs and the code that uses them. You still add the service's key or sign in once, but the assistant handles the rest.