User guide › Integrations & API
Two kinds of connection
It's worth separating these before anything else, because they live in different places and answer to different people.
| Kind | Belongs to | Where |
|---|---|---|
| Personal connection | You. Your calendar, your mailbox, your social account. | Settings → Integrations |
| Workspace channel | The company. The sender everyone's notifications go out through, the endpoints other systems talk to. | Settings → Channels (admin) |
Connecting your own Google account doesn't change anything for your colleagues, and configuring the workspace email sender doesn't touch anyone's personal mailbox.
Connecting your own accounts
Settings → Integrations is open to every member — you manage your own connections. The Available grid lists the providers your workspace has been set up for, grouped by what they're for:
| Group | What it covers |
|---|---|
| Sign-in | Signing in with Google, Microsoft or LinkedIn instead of a password. |
| Your own mailbox, either through a provider or your own SMTP/IMAP server. | |
| Calendar | Google Calendar, synced into the workspace as records. |
| Messaging | Meta (Facebook and Instagram) and WhatsApp Business. |
| Social | Publishing to connected social accounts. |
| Advertising | Ad accounts, discovered when you connect. |
| Commerce | Storefront connections. |
A provider that hasn't been configured for the workspace shows as Not configured rather than a Connect button — that's an admin job, not something you can fix from your own account. Groups with nothing in them simply don't appear, so the page reflects your workspace rather than a catalogue of everything that exists.
Click Connect and you're sent to the provider to authorise. You come back to Your connections, where each row has a Disconnect button. Some providers let you add more than one account.
What connecting actually does
Integrations don't get their own bespoke screens. Synced data lands as ordinary records on an entity, which means every part of the app you already know works on it — table and calendar views, filters, search, comments, dashboards. A synced entity is marked as such and can't be edited by hand; the sync is the only thing writing to it. You can still add your own views of it.
Synced data is scoped to whoever connected it. Your calendar events are yours — a colleague with the same entity open sees theirs, not yours.
A calendar linked with read-only access is labelled as such. Disconnect and reconnect to enable two-way sync, which is what lets you reschedule by dragging and edit events from inside the workspace.
Admins see an extra Workspace integrations section listing every connection across the workspace, so you can audit who has linked what and revoke it. Credentials themselves never leave the server and are never shown back to anyone.
Your own mailbox
The same page has an Email mailboxes section. Add mailbox stores your outgoing SMTP details — host, port, username, password, and whether the connection uses STARTTLS, SSL/TLS or neither — plus an optional IMAP block for incoming mail. Leave the IMAP host blank to skip it.
Test verifies the credentials, and the mailbox shows when it was last verified so you can tell a bad password from a bad address. This is a personal mailbox: it's distinct from the workspace sender described next.
Workspace email Admin
Settings → Email holds one set of SMTP credentials used to send mail "from the company" — invitations and system notifications, not messages from a particular person. You set the server (host, port, username, password, security) and the sender (from address and from name).
Send test pushes a one-shot message using the saved credentials, so save first if you've just changed a field. There's a Use Gmail shortcut that fills in the host and port people usually get wrong.
Gmail rejects your normal account password here. Create an app password in your Google account's security settings and use that, with your full Gmail address as the username. This is the single most common reason workspace email silently fails.
Message templates Admin
Settings → Message templates is a library of reusable message bodies, organised by channel: Email, In-app, WhatsApp, Messenger and SMS. Reminders, automations and flow actions pick a template rather than carrying their own text, so you change the wording in one place.
Templates are multilingual — each one holds a subject and body per language, and the right variant is chosen when the message goes out. Marking one template per channel as Default pre-fills it whenever someone picks that channel, which removes a decision from the common path.
Bodies can carry placeholders for field values and reminder details, so one template reads correctly for every record it's sent about. See Formulas & automations for what triggers them.
System notifications Admin
Settings → System notifications decides how the app's own events reach people — invitations, @mentions, assignments. Per event you choose which channels are used and which template carries the wording.
Sending data out: webhooks Admin
A webhook POSTs a record to an external URL when something happens to it. Settings → Webhooks is where you create them. Each one has:
- A name, for your own benefit.
- A trigger — record created, record updated or record deleted.
- An entity, or all entities.
- The URL to POST to.
On first save you're shown a signing secret. Copy it then — it isn't shown again. Your receiver uses it to confirm a request genuinely came from your workspace rather than from anyone who happened to learn the URL.
Each webhook has a toggle to disable it without deleting it, a test-fire button that sends a sample payload, and a History panel listing recent deliveries with their status, HTTP response code, duration and any error. That history is the first place to look when a downstream system says it never heard from you.
Receiving data: inbound endpoints Admin
The mirror image. Settings → Inbound endpoints creates a URL that an external system POSTs JSON to, which then lands as records on an entity you choose.
- Create the endpoint Give it a name and pick a target entity. Synced and read-only entities aren't offered — those belong to their own sync.
- Save the token You're shown the endpoint URL and a bearer token, once. There's a ready-made example request you can copy straight into a terminal to check it works.
- Map the payload Open the endpoint's Configure page and route each incoming JSON path to a field on your entity. Nominating an id in the payload makes repeat deliveries update the same record rather than creating duplicates.
The list shows how many payloads each endpoint has received and when the last one arrived — enough to tell "nothing is being sent" from "something is being sent and rejected". Endpoints can be disabled, and deleting one makes anything still posting to it start getting errors.
Pulling data in on a schedule Admin
Inbound endpoints wait to be pushed to. Settings → Data sources (BYOD) goes the other way: it calls someone else's API on a schedule and maps the response into your entities. Use it when the system you're importing from has no webhooks — which is most of them.
Create a source with a name, a target entity and the API URL. That drops you on the source's own page, where you configure the rest:
| Setting | What you choose |
|---|---|
| Authentication | None, a bearer token, a custom header, basic username and password, a key in a query parameter, or an OAuth client-credentials grant. |
| Response | Where in the JSON the list of items sits, plus pagination and an optional "only what changed since last run" parameter. |
| Schedule | Every N minutes, or a cron expression. |
| Mapping | Which path in each item feeds which field, and which value is its stable id. |
A test pull fetches the first page and shows you the real response with the mapping applied, without writing anything — so you wire the mapping against the actual shape rather than guessing from documentation.
Import bundles group related sources — leads, plus their comments, plus their reminders — so they import together on one schedule, parents first, with the child records linked to their parents. The list shows how many records each source has imported and when it last ran, and a source can be paused with its toggle.
Point a new source at a small slice of data and check the first run landed the way you expected before you widen the URL or shorten the schedule. Repeat runs update the same records only if you've nominated an id — without one you'll accumulate duplicates.
Public forms as a way in
The lightest inbound route needs no code at all. Any entity can publish a public form: a URL you give to people outside the workspace, whose submissions arrive as records on that entity. You choose which fields appear and how they're laid out, the message shown after submitting, and optionally a URL to redirect to instead.
Forms can be disabled without being deleted, and deleting one stops its URL working immediately. They're managed per entity — see Views & filters.
API tokens Admin
Settings → API tokens issues long-lived tokens for scripts, integrations and CI. A token runs as the person who created it and inherits that person's permissions — it can't do anything you couldn't do yourself.
When generating one you give it a name, optionally an expiry date, and optionally restrict it to specific parts of the API. Leave it unrestricted and it carries your full access; restrict it and it's limited to the areas you tick.
The token value appears exactly once, at creation. After that the list shows only its first few characters, who it runs as, its scopes, when it was last used and when it expires. Lose it and you generate a new one.
Revoke kills a token immediately — anything using it starts failing on the next request. The Last used column is the quickest way to find tokens nobody needs any more.
The API reference
The API reference button on the tokens page opens a live, generated list of every endpoint the app exposes, grouped by area, with a badge showing whether each is public, requires a signed-in user, or requires an admin.
- Search by path or area, and filter by access level.
- Paste a token at the top and Test token tells you which user and workspace it resolves to, and whether that user is an admin.
- Every endpoint shows its input fields with types and which are required, plus a copy-pasteable example request using the token you pasted.
- Try it runs a real call from the page, with plain-English hints when it comes back unauthorised, forbidden or invalid.
- The whole thing can be downloaded as a Postman collection.
Because it's generated from the running server rather than written by hand, it doesn't drift out of date.
Choosing the right route
| You want to… | Use |
|---|---|
| Let a colleague's calendar or mailbox appear in the workspace | Settings → Integrations, connected by them |
| Tell another system when a record changes | Webhooks |
| Let another system send you records as they happen | Inbound endpoints |
| Copy in data from an API that can't call you | Data sources (BYOD) |
| Collect submissions from people with no account | A public form |
| Write a script or wire up a tool of your own | An API token plus the API reference |