Integrations

Settings › Integrations. Your application does not hold an email provider's key or speak an SMS vendor's API. It asks the platform, and the platform does the work with whatever you configured.

Asked for before they are connected#

An application can be built to use something before anybody has the account for it. Tick it on the creation screen — What should it be able to do? — and the first build writes the code that sends the email, then carries on quietly without it until it is connected.

The Integrations screen leads with anything in that state: this application was built to use Email, and it is not connected yet. Connecting it needs no rebuild; it works from the next request.

That is worth doing in that order. Retrofitting email into an application that was never built with it in mind is a change; leaving a path it already has is a setting.

What is available#

Connecting one#

Choose the capability, choose the provider, paste what it asks for, and press the test.

Testing is a real send. A credentials check that passes and then fails on your first customer is worse than no check at all.

• Email goes to an address that accepts and discards it, so nothing lands in anyone's inbox and it costs nothing.
• SMS has no equivalent, so it asks for a number and costs one message. That is said plainly rather than charged silently.

Google#

Connected per application, by consent — you are taken to Google, you approve it, you come back.

Per application rather than per workspace on purpose: a client-facing application and an internal one can use different accounts, and revoking one leaves the others working.

Why this is the shape it is#

Four things follow from the platform holding the credential rather than the application:

• You configure a service, not a library. Nobody installs anything.
• Switching provider is a settings change. The same application sends through Postmark today and Mailgun tomorrow, with no rebuild and no build spent, because it only ever knew "send an email".
• Credentials never reach the application. They stay encrypted on the platform. An application that is compromised cannot walk off with your email account or your Drive.
• One implementation to keep working. A provider changing its API is one fix here, not a rebuild of every application that used it.

The cost is real and worth stating: a service we have not implemented cannot be used this way at all. An application can still call an ordinary HTTP API with a key you put in Configuration — it just does not get the properties above.

Using them#

Once a capability is connected, the builder knows it is available and will use it when you ask:

Email the site engineer when a visit is assigned to them.

Text the customer the day before their appointment.

Put a copy of each signed report in our Drive folder.

Disconnecting#

Stops the capability. An application that tries to send afterwards gets a failure rather than sending through something unexpected.