Connect your tools

Start with the tools you use

Connected tools appear first. Expand Available tools when you want to add a provider. If nothing is connected, enable managed connectors in setup and connect a source. A connected badge shows account configuration; live verification requires a successful provider run and its receipt.

Page layout

Connections starts with a health table of saved connections, their read operations, latest read receipts and server-reported states. Beside the connection state, needs verification means nobody has yet recorded this provider's reads working against the live vendor, so check the first results before relying on them; live verified means that run is on record. Open Add or manage connections to use the existing setup controls. CRM coverage, import activity, CSV import and advanced setup remain below. The table scrolls on smaller screens.

Overview

Sales as Code runs the work for you on a schedule, on our servers. There is nothing to install: no desktop app, no plugin, no marketplace. You connect your tools once, we custody the token, and the scheduled runs read your book and draft the work. Connect starts with the CRM because it gives your first standup useful context, then shows other import and advanced paths only when you open them.

Power users who want to drive the account from their own scripts or an MCP client can still issue a key. That path moved to Settings, Advanced, see API Keys & MCP. It is optional and not the main flow.

What it shows

• Connection state. Each connected tool with its last sync time, and a Sync now button to pull your book immediately. When a tool's authorization expires or you revoke it at the provider, the next scheduled read notices and flips that tool to needs reconnect on its own, so a dead login surfaces as a clear reconnect prompt instead of a connection that quietly stops syncing.
• Reconnect needed is its own badge. A dead authorization and a bad afternoon at the provider are different problems, so the panel stops drawing them the same way. A revoked or expired grant gets an amber reconnect needed badge and one line telling you to reconnect. A rate limit or a provider outage stays a plain error and clears itself; you do not need to touch it. That includes the provider's sign-in service being down while we renew your access. Reconnecting through the provider's sign-in clears the badge as soon as you finish, without waiting for the next sync. The card no longer shows you the provider's raw message, which named an HTTP status and no remedy.
• A refused key shows up even when no sync ran. Several tools are used between syncs, not only during one: an Apollo lookup during your first launch, the Instantly campaign list, a send to a Clay table, a Planhat task or note, a Teams post. When the tool refuses the key there (a 401 or 403), or a Teams webhook has been removed (a 404 or 410), that card turns to reconnect needed with the reason, instead of the one action failing while the card stays green. Pasting a new key, or enabling Clay again, clears it, and so does the next signed delivery Clay sends. Planhat has no way to ask what a token may write, so its writes are confirmed on the first one.
• A throttled send is not a failed one. When Slack or Teams is still rate limiting a post after our retries, the post was not accepted, so an approval that triggered it can be tried again rather than held as unknown. A Clay table that answers 429 is not written either: the send waits until the time Clay gave, then the same request can go through. Pressing it again before then is refused without contacting Clay.
• What has arrived. The last ten things your connected tools reported, newest first: which tool, what kind of event, and how long ago. This is the difference between a token that works and a tool that is actually sending you something, and the status card above can only answer the first. A green connector with nothing in this list means the login is fine and the tool has been quiet. The list shows the event summary only, never the contents, because an event shared with your team can belong to a teammate.
• A credential we can no longer read counts as needs reconnect. If the key your tokens are stored under is rotated, the stored credential stops decrypting. Nothing has failed yet, because nothing has tried, so there is no error to show. The panel used to read a healthy green connected in that state. It now says reconnect, which is what actually has to happen.
• Degraded, when part of a sync did not finish. A connector that reads more than one kind of record (Salesforce reads opportunities, accounts and contacts; HubSpot reads companies, deals and contacts) can have one of them fail, or run into a read limit, while the rest come back clean. The card names which one and leaves the others reading as current, instead of the whole tool reading as failed over a book that is mostly fine.
• WordPress, Webflow and Notion never overwrite an edit made there. Before updating an item it already published, the destination is read first. A WordPress post's modified_gmt, a Webflow item's lastUpdated or a Notion page's last_edited_time that no longer matches the time recorded after our last write holds the publish in Studio as changed in that tool, with nothing written. A WordPress post in the trash, and a Notion page archived or in the trash, count as deleted. A rate-limited read, or an update of an item already held, waits as the tool asks and tries again, at most three times; a rate-limited create is not repeated. All three stay in preview until a live site or workspace confirms these fields.
• Planhat and Gainsight writes report what the tool said. A Planhat company, deal or renewal update names the record revision it was reviewed against. The record is read first, and a newer revision, or a conflict Planhat reports on the write, stops it with nothing sent. A Gainsight Timeline write counts as done only when the reply says it succeeded with no record error. An error on the record is a failure, an activity id that already exists is a conflict, and a reply that says neither is held as unknown rather than recorded as done.
• A destination takes an id as well as a token. WordPress needs your site address, Webflow a collection id, Notion a database id, Mailchimp an audience id, Customer.io a campaign id and a region. Those are fields on the tile, each with where to find it, and each checked as what it is: pasting the page address into an id field, or the collection name instead of its id, is refused with a sentence naming the field rather than saved and discovered as a 404 later. An id is not a secret, so what you saved stays visible; the token never does.
• Customer.io reporting has its own signing key. After the App API token is connected, its card shows a receiver URL and a separate password field for the reporting webhook signing key. The vendor-owned key stays encrypted and is never shown again or changed by the automatic app webhook rotation. Signed reporting events are stored before they are processed. Duplicate event ids are counted as replays, abandoned processing can resume safely, and provider identities are linked to tenant contacts so an unsubscribe remains effective even when the report omits the email address.
• HubSpot Marketing and Mailchimp opt-outs hold the address. Each Mailchimp poll reads the whole audience with each person's consent state. A HubSpot Marketing poll reads the segment's member list in full, then re-reads contacts and consent only for people who joined or changed since the last poll, and everyone once a day. It follows every marketing email the app published there, not only the one you configured: an email is re-read when HubSpot says it changed, and its send totals every poll. A Mailchimp member marked unsubscribed or cleaned, and a HubSpot contact unsubscribed from all email or flagged as a bad address, is held from research, contact selection and every send, by exact address. A later resubscribe in the same tool lifts only the hold that tool set, so an opt-out recorded by Customer.io, a CSV file or you still stands. Leaving the audience is not a resubscribe and lifts nothing. Both connectors stay in preview until a live account confirms the consent fields.
• Which webhook secrets rotate on their own. Only ones you pasted into the other tool yourself, such as Clay or a generic inbound webhook, and only when the connection has had no activity for 30 days. The new secret arrives by email for you to paste in, and the old one keeps working for 72 hours after the rotation, so deliveries your tool signs before you make the change are still accepted. The email says when the old secret stops. Replacing a secret yourself by enabling the webhook again stops the old one at once, because that is what you do after a leak. A connection that is receiving events keeps its secret; enable the webhook again to replace it yourself. Intercom, Attio, Instantly and Customer.io are never rotated automatically: their secret is either the vendor's own or was registered with the vendor when you connected, so changing our copy would stop their webhooks. To replace an Attio or Instantly secret, disconnect the tool and connect it again.
• PostHog reads your project, not this product's analytics. Paste a personal API key with query read access, choose the project region and enter the numeric project id. The connector keeps only the event id, event and ingest times, approved campaign fields, path, and the one identity you choose under Match events to customers by: the email on the event (the default), the email on the PostHog person, or a company domain held in a person property you name, such as company_domain. An email on the event always wins. A company domain matches an account you already have and never creates one. Anonymous ids stay unmatched in every mode. Exact checkpoints resume large histories without skipping events that share a timestamp, and changing projects starts a fresh bounded read.
• Re-read the last N days. A connected card that reads records carries a day count and a button. Setting the window and running it clears that connector's watermark and reads again from N days back, on demand, without waiting for the next scheduled poll. Useful after fixing whatever caused a degraded read, to recover what that read missed.
• Re-read the last N days. A connected card that reads records carries a day count and a button. Setting the window and running it clears that connector's watermark and its stored checkpoints, and reads again from N days back, on demand, without waiting for the next scheduled poll. Useful after fixing whatever caused a degraded read, to recover what that read missed.
• An import that stops part way resumes where it stopped. Each object keeps its own checkpoint, written only by the pass that walks history oldest first. A connector that also re-reads changes (Attio has no record-level updated timestamp, so it re-reads the newest records of the last 30 days and a rolling slice of the rest) cannot move that checkpoint forward past records still to be imported. A poll that hits the per-poll page or row ceiling records what it read and the next poll continues from the last record it landed, so a 1,500-record import finishes across two polls rather than losing the middle of it. An object whose read failed keeps its checkpoint exactly where it was, and the card names that object.
• Tools that list newest first, or do not say. Fathom, Zoom and Gong keep the start of the window they are reading until every page of it is in, and save the page they reached with the checkpoint. A read that hits the ceiling or fails on a page carries on from that page at the next poll, so older meetings and calls are never stepped over. Zoom reads month by month from where it last stopped up to today, so a Re-read the last N days further back than a month reads all of it. Each also looks again at recent work, because a meeting's notes arrive after the meeting: Fathom reads the last seven days again on every poll for new action items and transcripts, Zoom the last three days for transcripts and summaries, and Gong asks again for any call it stored without a transcript, for up to a week after the call. Stripe reads its customers, subscriptions, invoices, refunds and changes the same way, so a read that fails after its newest page no longer moves past the older ones. Intercom walks your whole conversation list with a saved place too: a read that stops on page 400 carries on from page 400 at the next poll rather than starting again from the first page.
• Import paused, and Retry from checkpoint. When a sync stops on one object, Connections shows Import paused on a record, marks that connection paused on the object in the health table, and draws an import receipt: the last durable checkpoint (the object, the last record it holds and when it was saved), the first failed record and the reason in plain words, and the rows confirmed for that object. A connector read fails on a page rather than a row, so the provider does not name the record it could not read; the receipt says so and names the last record the checkpoint holds instead. Retry from checkpoint runs the same read as a scheduled poll: it starts at the checkpoint, clears nothing, and records are keyed by the provider's own id, so the overlap updates rows rather than adding them. Re-read the last N days is the other control, and it does the opposite: it clears the checkpoint to read further back.
• The overview controls. Under the health table, Add a destination opens two panels side by side: Destination setup, with a Provider choice of every destination that takes an id (Webflow, WordPress, Notion and the others above) and that provider's destination fields, token, Check access and Save; and Access preview, which lists what the connection could do once access is checked. It starts on the first destination you have not connected. Close destination setup puts the form back on its card. With managed connectors off, the button points you at the switch first. Inspect import moves to the receipt of a paused import. It is greyed out, with the reason on hover, when no import has run or when none is paused. Under Contracts and conflicts, Review CRM conflict shows how many CRM changes are held and moves to the first decision, and is greyed out when none is held. See verification ledger opens what has been verified against a live account below; a deployment admin gets the full provider register instead.
• An older copy never replaces a newer one. When a tool sends the same record twice, or a webhook arrives after a later change already landed, the copy with the older change time is ignored. The record keeps its newest state, and a re-read at the same time still refreshes it.
• How Attio and Zoom tell which copy is newer. An Attio record has no updated time of its own and its created time never moves, so each record is dated by its newest field change: every Attio field value carries the moment it became current, and the latest one is the record's change time. A Zoom recording and its deleted copy in the trash are both dated by the meeting's start time, with the deletion time kept alongside, so whichever the latest poll saw wins. A recording you restore from the trash comes back on the next poll that reads its date: the next scheduled poll for a recent meeting, or Re-read the last N days for an older one.

How to read a card

Under the badge and the last-sync line, a connected card lists what it reads (each kind of record, with the count landed and how long ago the newest one arrived), what it writes back and on whose say-so (every write waits for your approval, or "off" when no write path exists for that tool), and how often it polls, with the per-poll read limit. Underneath that is the account of the last read: how many rows came back, how long it took, and, on a degraded read, which record kind did not finish. The same facts, plus the vendor doc a connector was written against, are in integrationCapabilities() (src/lib/integrations/capabilities.ts), which this card and the docs page both read, so the two cannot disagree about what a connector does.

Every connection, and what it can do

The directory below is generated from the provider registry, the writeback adapters and the projectors, so a connection can only appear here by being registered, and a tier can only read what its own file declares. For each connection: what it reads, what it can write and the approval that covers a write, which outcomes reach your accounts, contacts or signals, how fresh it is, what access it needs, its read limits, and the date it was last run against a live vendor account. Where that date is missing, nobody has run it live from this codebase yet, whatever the tier says about the code.

Where to find it

Settings, then Connections. One tab, one page. It used to be two, "Connections" and "Advanced", and they landed you in the same place by way of a redirect. Everything is on this page now: the managed connectors below, and the power-user path (an API key, MCP, a self-hosted n8n kernel) further down.

Connect your CRM, inbox, and calendar

The Connect page carries a managed connectors panel. We custody your token, encrypted and isolated to your tenant, poll it on a schedule, and fill your accounts, opps, and contacts server-side. The panel shows each provider's connection state and last sync, and Sync now pulls your book on demand.

Open See CRM read and write coverage below the connector panel to check the exact scope for HubSpot, Attio, Pipedrive and Salesforce. Each card counts the record families and approved actions with a code path, then names what remains open. This coverage is separate from connection state and live vendor verification.

When someone edits the same field in the CRM first. A change we propose to a HubSpot, Salesforce, Attio or Pipedrive record remembers the value it was proposed against. Before writing, we read the record again. If that field has changed since, we do not overwrite it: the write is held for review with the old value, the value in the CRM now, and ours, and it is not retried on its own. Salesforce also sends the update on the condition that the record has not changed since that read, and a vendor that answers "conflict" (409 or 412) is held the same way. Fields Salesforce derives from the stage, such as probability, are written through. The receipt for a held write says held for review. Every change we make to a field on an existing CRM record now carries that value: a next step an agent proposes, a hygiene fix, a MEDDPICC push and the closed-won handoff. When the field was empty, the change says so, so a value someone typed in since is held too. A hygiene fix to a close plan or a competition note writes into the opportunity's Description, which we do not keep a copy of, so we read Description from Salesforce or HubSpot just before the write and hold the write if it changes in between. If that read fails, nothing is written and the result says so.

Deciding a held change. Held changes wait in the Resolve field ownership panel, which appears under Connection health only when a change is held, when the list could not be read, or when a receipt linked you here. With nothing held, Review CRM conflict is greyed out and says so. Each one shows the record, the field, the value it was proposed against, the value in the CRM now and ours. Choose Keep the CRM value (nothing is written), Apply my value, or Enter a value, then Save decision. The result says what happened and whether anything reached the CRM. A value you apply is checked against the value the CRM holds now, so a further edit in the CRM holds it again rather than being overwritten. Keeping the CRM value needs only a sign-in; writing a value needs an active product. The receipt for a held write links straight to its decision, and once the page has loaded the cursor waits on that decision's resolution menu.

What a CRM write records. Every HubSpot, Attio, Pipedrive and Salesforce write keeps the record id the CRM answered with, the status it sent and, where the CRM sends one, the revision or modified time, and Receipts shows them. Every call a sync, a CRM write, a publish or a send makes is also counted for your workspace, by tool, on the Tool usage card under Settings, API & AI. A write whose answer was lost is never sent again. An hourly check reads the record back and marks the write applied when the record holds every value it intended; otherwise it stays unknown for you to check. These read paths have not yet been run against live accounts.

Our own writes do not come back as news. When the next sync reads back a stage we just wrote, it is not recorded as a stage change made in the CRM. A change someone makes after ours is recorded as usual. These checks are built and tested against each vendor's documented API; none has yet been run against a live account.

What you can link in the browser:

• CRM. Salesforce, HubSpot, Pipedrive, Attio. Attio's API has no way to ask "what changed", so instead of missing edits it re-reads records each poll: the newest records created in the last 30 days, and the next 200 of every company, person and deal in turn. Once it reaches the end of the list it starts again, so an edit to an old record lands within one full pass, and you no longer need Re-read the last N days to pick it up. On a workspace with 2,000 companies and a sync every 30 minutes, a full pass takes about five hours.
• CRM tasks, notes, calls and meetings. HubSpot tasks, notes, calls and meetings, and Attio notes and tasks, appear on the account they belong to: a HubSpot activity on the company it is associated with, or the company of its deal or contact, and an Attio note or task on the company of the record it is linked to. An activity on a record you have not imported, or on one that was deleted, is not placed on any account.
• Inbox and calendar. Gmail and Google Calendar, or Outlook and Microsoft Calendar. A calendar meeting keeps the email addresses of the people outside your company, leaving out your own address and anyone at your domain, so a meeting with someone who replied to your outreach is added to the deal opened for them.
• Revenue. Stripe, for customers, invoices and subscriptions, read through Stripe's Events API so a subscription that changes status without a new invoice is still picked up. An invoice that changes is read again in full, so a refund still lines up with the invoice it came from.
• Product analytics. PostHog, for usage and conversion events from your own project. Campaign evidence is joined to your content only inside your tenant and only for the currently connected project. The connector is preview until a controlled project verifies the live query path.
• Google Search Console (preview). The Google searches that showed your own site in the last 28 days: queries, pages, clicks, impressions and average position. It is a separate Google sign-in that asks for read access to Search Console and nothing else, so connecting it changes nothing about your Gmail, Calendar or Drive connections, and disconnecting it leaves them alone. The card stays greyed out, with the reason on hover, until Google has approved this app to read Search Console data. Once connected, we read once a day, only the property whose address matches the website on your business brief, and show the results under What buyers searched to find you in Studio. The Search Console API has no per-read price, so it counts nothing against your credit budget.
• Meetings. Calendly and Fathom, for booked meetings and whether they held, Fathom transcript included. A Calendly booking carries the invitee's email address, so it reaches the deal opened for that person. Zoom, for recordings, meeting summaries and the transcript file when the recording has one. Google Meet and Teams transcripts, matched to the calendar invite so the call lands on the account of the person you met. Gong, for recorded calls and their transcript. Every transcript keeps who said what and roughly when, not only the flat text. Each open Fathom action item and each Zoom next step becomes an action item of its own, linked to the deal opened for the person on the call and to their account, with the owner Fathom named and due a day after the call when the tool gave no date. Reading the same meeting again does not add a second copy, and an item you already closed stays closed. Open items show under the deal on Deal Inspection with the meeting they came from, and on Today. Mark done on the deal closes one.
• Files. Google Drive, which covers Docs, Sheets and Slides: where you point the business brief, and where exports land.
• Go-to-market data. Hunter, Apollo, ZoomInfo, Cognism, Sumble and Clay. A key you paste here is your own, and the enrichment cascade spends it before any key the deployment holds. ZoomInfo and Cognism connect once your agreement with them includes API access; the card says so. Clay works the other way round: the card mints a webhook URL and secret you paste into a Clay table, and every row Clay enriches lands on the contact record here. Sending to Clay is always your call. A target with auto-fire topics does not send when a gap matches: the send waits under Enrichment sends waiting for you on the Team page, naming the target and what it would send, until you approve it or dismiss it with a reason. Approving sends it once, even if you press it twice. Clay has no way for us to read a table back, so a row it sent while our receiver was down cannot be fetched later. Instead the Clay card watches its own side: when sends Clay accepted have had nothing come back for a day, it says deliveries may have been missed. Map the outbound requestId into each returned row using the same field name. Only a return with that request ID clears the unanswered-send warning; unrelated rows cannot clear it. A linked row proves a return arrived, not that every requested fact was found. Include creditsUsed as a nonnegative number for that row when the table reports its cost. Missing cost remains unknown, and returned costs are evidence only, not a change to your billing or allowance. To resend, open the table in Clay, select those rows and run the webhook column again; a row that already arrived is updated, not doubled. If you send to Clay without a table of your own, the send goes to the deployment's shared Clay table, which spends the deployment's Clay credits: that needs a paid plan, and each send counts against your platform allowance on Enrichment Budget. When Apollo finds no contacts at an account, the contact finder can fall back to the deployment's ZoomInfo key; each contact it asks for counts one credit against your allowance, and any it did not get back are returned. Apollo's people search is free, so it never counts.
• Support, sequences, partners, success and demos. Zendesk, Intercom, Salesloft, Outreach, Instantly, Crossbeam, Planhat, Consensus. Outreach replies and sends land as account signals, and an approved action can add a contact to a cadence. Instantly asks for an API key, a campaign ID and the exact sending account. Its live enrollment path remains preview until a controlled account run proves it. After Intercom connects, its card mints a webhook URL and accepts the app client secret used to verify conversation events, Fin resolutions, and deletion notices. A closed Intercom conversation, or one Fin marked resolved, counts as the resolution of any support escalation opened on it, the same way a solved Zendesk ticket does, and outreach to that account stays paused until someone reviews the next action or 14 days pass. A conversation the customer reopens is activity, not a resolution.
• Deleted support and success records leave the book. A Zendesk ticket deleted in Zendesk is removed from your tickets at the next sync, with the support signal it put on the account, so outreach is not held for a ticket that no longer exists. Planhat has no list of deleted records, so each sync reads every company, task, conversation, deal and line item list in full; a record that was there last time and is missing now is treated as deleted, and its account or signal is removed. A list too long to read in one sync (over 100,000 rows) carries on at the next one, and nothing is treated as deleted until a sync reads that list from the start to the end.
• Planhat and Gainsight read in an order an edit cannot change. Planhat lists are read by record id and Gainsight lists by created date, oldest first, so a record edited during a sync is neither read twice nor skipped, and a sync that stops part way carries on from the page it reached. When Gainsight answers that too many requests arrived, the read waits the time Gainsight asks for, up to 30 seconds and twice, before it reports the sync as failed.
• Calls. Gong, once a Gong administrator has enabled API access for your org. The card says so and names who to ask, rather than offering a button that cannot work yet.

Trigify (a Data card) reads who reacted to or commented on LinkedIn posts about your topic and by the competitor pages you watch, on your own Trigify API key from Settings, API Keys in Trigify. No key, no read, and nothing is read on a deployment key. Reads happen only when you press Read now in Content Studio, one at a time and at most four times a day, and each post or engager read counts one credit against your Enrichment Budget as well as spending a credit on Trigify. Topics and post data need Trigify's Enterprise plan. Without Trigify, import a CSV of engagers in Studio instead.

Zoom, Google Meet, Teams transcripts, Sumble and Trigify are marked preview: written against the vendor's published API and not yet run against a live account from this codebase. The badge comes off when they have been. Teams transcripts also need a Microsoft 365 administrator to consent to transcript reading once for the organisation; until then the card shows the permission error Microsoft returns.

X for market reads is also marked preview, and it is a second, separate credential from the X connection that publishes posts. Publishing uses the sign-in on this page. Reading what your market says on X uses a bearer token from your own app in the X developer portal, which you paste under X reads on your own key in Studio, so X bills those reads to you and never to us. Nothing is read from X without that token, each request counts one credit against your credit budget, and removing the token stops the reads. Company news in the same list comes from the free GDELT Project and needs no connection.

A transcript is stored as speaker turns, not one block of text, up to two hundred thousand characters of speech per call, cut at a turn boundary rather than mid-sentence if a call runs longer than that. The post-call follow-up reads its own four-thousand-character summary of the call, cut separately, so a long call still gets a short brief.

Contribute company facts to the shared pool. A switch under the panel, off by default. When it is on, what your enrichment runs and research find about a company (industry, size, location, stack, a dated change with its public source) joins a pool keyed on the company's domain that every tenant's cascade reads before it spends a credit. Nothing about a person enters it: no name, no email, no phone, no title, and no tenant id. You read the pool whether or not you contribute. The rule and the test that pins it are in Contact Enrichment.

Until September 2026 this panel offered four of those, while the mappers behind Attio, Pipedrive, Stripe, Calendly, Zendesk and Fathom already worked. The data had somewhere to land and no way in. The list is now held to the mappers by a test, so a connector that learns to fill your book cannot again be one you have no way to link.

Pipedrive reads from your company's own API address, the one Pipedrive names when you connect, rather than the shared one. Connections made before September 2026 keep the shared address until you reconnect. Pipedrive imports organizations and people before deals, so a deal's account reference and a person's organization reference point to records in the same book. Deletion markers remain visible instead of silently removing history. Deals are read from Pipedrive's recent changes, and a sync that stops part way carries on from the page it reached, so older deals are not skipped. That read includes deleted deals, and a deal deleted in Pipedrive leaves your book on the next sync. Each deal carries its stage name from your pipeline's stage list, so a stage we set is not recorded as a change someone made in Pipedrive. Live Pipedrive verification remains open until an authorized workspace is available.

A Salesforce task or event deleted in Salesforce is removed from the account it was shown on at the next sync.

Instantly setup records one campaign and one sending account. An approval covers one recipient and one saved revision. The product does not treat Instantly as a raw email sender, because the vendor runs content already saved in its campaign. Pause and resume act on the exact campaign. Stopping one recipient requires the Instantly lead reference and removes that lead from the campaign. These controls remain unavailable until the live adapter is verified with an authorized Instantly account.

An Instantly action that got no clear answer, such as a rate limit or a timeout, is held as unknown and never repeated. An hourly check asks Instantly: an enrolled lead in the campaign, a campaign in the approved state, or a removed lead that is gone settles the action. Anything else leaves it held for you to check in Instantly. An accepted enrolment is logged to your connected CRM as an enrolment, once per Instantly lead, the same way a sent email is.

Connecting Instantly also subscribes two webhooks on your workspace, one for replies and one for bounces, each carrying a secret only your connection knows. A reply or a bounce Instantly reports stops further sends to that address from here: approvals, Instantly enrolment and the daily-prospecting follow-ups. If the bounce webhook cannot be created, the connection says so and replies still stop sends; connect again to retry it. Every hour the connection also reads Instantly directly: replies in the unibox since the last one it read, and the state of every person you enrolled through an approval. A reply sent before the webhook existed, or while it was down, still stops the next send, and a person Instantly marks as bounced is held the same way a bounce webhook would hold them. A reply seen both ways is recorded once. Replies also appear as reply signals on the person's account.

This is opt-in, per account, and reversible. You can revoke a connection at any time. A security-strict team can leave it off and drive the account through the advanced API path or its own n8n instead. The same panel appears in every persona console under Settings.

Gmail and Google Calendar

The first Gmail sync reads the last seven days of threads. After that, each sync asks Gmail what changed since the last one, so a reply on a thread from last year is read the same day, not only mail inside a recent window. If a first sync has more mail than one sync reads, the next sync carries on from where it stopped rather than skipping the oldest part. Gmail forgets its change log after about a week; a mailbox that has not synced for that long reads again from the last mail it saw, at most 30 days back.

A thread you delete or move to the trash in Gmail is marked deleted here. It stops counting as a reply, and the reply check stops reading it.

Google Calendar keeps its place by when a meeting last changed, not when it starts, so booking a meeting for next month no longer hides the changes made before it. A sync that stops part way keeps what it read and picks up after it.

A Gmail draft that fails with a server error on Google's side is not sent again automatically, because Google may have saved it before the error. It is recorded as unknown, and the receipt asks you to check Gmail before retrying, so you do not get two copies of one draft.

An approved Campaigns answer to someone who replied to one of your Gmail sends goes into the same conversation: it is sent with the original's thread and names the original message, so their mail client shows it as a reply. Like every Gmail send, it is posted once; a server error is not retried automatically, because Gmail may have sent it before the error. The in-thread send is written against Google's published API and has not yet been run against a live mailbox from this codebase.

These reads use the Gmail read permission you already granted. They are written against Google's published API and have not yet been run against a live mailbox from this codebase.

Outlook and Microsoft Calendar

Until September 2026 there was no Microsoft connector of any kind, which took out three things at once for anyone not on Google: approved drafts had no mailbox to send from, replies could not be detected, and the meeting surfaces were empty. Both now connect the same way Google does.

Connecting Outlook does two jobs. It reads your threads as account activity, and it becomes the mailbox your approved drafts send from, using your address, your domain and your thread, so the reply lands where we can find it. If you connect both Google and Microsoft, Google sends: it is the older path and the verified one.

Both Microsoft connectors are marked preview, which on this site means written against Microsoft's published API and not yet run against a live Microsoft 365 account. The badge comes off when it has been.

Each sync checks the connection holds the mail or calendar permissions it reads with, and says reconnect when one is missing. Microsoft lists only those permissions in what it grants, not the sign-in ones such as staying signed in, and may write them in lower case, so neither reads as a missing permission.

We read message and meeting headers only. The body of an email is never fetched, on the poll or on the reply check. Microsoft's calendar change feed returns an invite's body along with the rest of the meeting; we drop it on arrival and never store it.

Each sync asks Microsoft what changed in your inbox, your sent mail and your calendar since the last one, so an edit to an older message or meeting is read too, not only new mail in a recent window. If a sync stops part way, what it read is kept and the next sync carries on from the last complete point rather than starting again. If Microsoft resets the change feed, the next sync reads again, at most 30 days back. The calendar reads 60 days ahead and starts a fresh read whenever fewer than 30 of those days are left.

A meeting deleted in Outlook is marked cancelled here, keeping its time and attendees. A message deleted outright, or a conversation whose every message is in Deleted Items, is marked deleted: it stops counting as a reply, and the reply check stops reading it. A message moved to another folder is not a deletion. A new message in that conversation brings it back.

When an approved email answers a message in your Outlook inbox, it is sent as a reply inside that conversation rather than as a new thread. Every Outlook send also carries a reference of its own, recorded before the send, so a send whose answer was lost can be found in your mailbox afterwards (see Receipts).

Keeping your mailbox healthy

Your outreach goes out from your own Gmail or Outlook, so its reputation is yours. When you connect either one, we read the address the mailbox sends as and look up three public DNS records for its domain. The result shows under the Gmail or Outlook card, and it is read again once a day.

• SPF lists the servers allowed to send as your domain. Without it, Gmail and Outlook are more likely to junk or refuse your mail.
• DKIM signs each message so a receiver can tell it came from you unchanged. A domain can use any name (a selector) for its key, and we can only try the common ones: google, selector1 and selector2. When none answers, the card says "not found with the common selectors" rather than "missing", because your domain may sign with another name. Check your admin console before adding one.
• DMARC tells receivers what to do with mail that fails SPF and DKIM. Google and Yahoo require it from anyone who sends in volume.

Each missing record links to your provider's own setup page. When DNS does not answer, the card says it could not check, never that a record is missing. A personal gmail.com or outlook.com address has its records kept by Google or Microsoft, so the card says there is nothing to set. Check records again repeats the lookup now.

We also count bounces: mail sent from this mailbox that came back from mailer-daemon or postmaster as undeliverable. When at least 5% of the mail sent in the last seven days bounced, and at least three messages did, the mailbox is paused: no new drafts are written for it, and nothing sends or lands in its Drafts folder from here. Mail providers start sending a mailbox's mail to spam when bounces pass a few percent, so the pause comes early. The three-message floor keeps one mistyped address in a quiet week from pausing you. The card and Home both say how many bounced and why it matters.

While a mailbox is paused, every send control for one of its drafts (the queue's Send, Campaigns and console approvals, Approve and place in Outlook, and the Gmail draft button) is disabled, and hovering it gives the reason. Beside it is I checked this address. Check the recipient, choose it, and that one draft can send to that one address; every other draft from the mailbox stays held. Where the page does not already know the recipient, it asks which address you checked. We record who cleared which draft, for which address and when, and the clearance counts only for that draft, that address and the current pause. Drafts placed in the mailbox by anything else (write proposals, policy runs, launch drafts, Teams approvals) are refused outright while paused. Buyer portal update emails still reach your buyers, sent through our mail service with you as the reply-to address instead of through the paused mailbox. To lift the pause for everything, remove or correct the bounced addresses, then choose Resume sending. Bounces from before the resume stop counting.

Tokens, and what each card asks for

Some connectors use an OAuth handshake and open a sign-in window. The rest take a token you paste, and each card names the one it wants rather than saying "token" and leaving you to guess. Zendesk is the one that asks for three things in a single field, in the form subdomain|email|token.

If a sign-in connector has not been set up on the deployment you are using, its Connect button is disabled and the card says so. Pressing it used to open a window that failed with a server error, which told you nothing you could act on.

HubSpot has no OAuth handshake, so instead of a Connect button it takes a private-app token. Click Add token on the HubSpot card, paste the token, and save. We encrypt it at rest and read it on the schedule exactly like an OAuth token, and Replace token swaps it later.

Check access before you save. Every card that takes a token has a Check access button beside Save. It sends the token and the destination fields to the same check Save runs, stores nothing, and shows an access preview: whether the provider accepted the token, and which operations the saved connection allows (read, drafts, publish, write), each marked allowed or not part of this connection. The list comes from what the connection's code can do; the check confirms the token, not each operation. A provider with no check we can run before storing the token says Access cannot be checked before saving rather than passing. Customer.io is checked in the region you chose, so a key from the other region is named as a wrong Region instead of being saved.

The token is checked with HubSpot before it is saved, and so is every replacement. We read one record each of companies, contacts, deals, tasks, notes, calls and meetings, which is everything the sync reads. A wrong token is refused. A token missing any of those is refused with each missing one named, all at once, rather than one per attempt. When HubSpot lists the token's scopes, the two the writes need, crm.objects.contacts.write and crm.objects.deals.write, are checked as well; when it does not, a missing write scope shows up on the first write instead.

Other tokens are checked the same way before they are saved, on first connect and on every reconnect. The site address, collection, database, segment or project you entered on the card goes into the check, so a token that works but cannot see the one you chose is refused then rather than on the first sync:

• Attio. The scopes Attio reports for the token are checked against record reads and writes, object lists, notes and tasks, and each missing scope is named. If Attio does not report them, one record, note and task are read instead.
• HubSpot Marketing. The marketing email, the segment, contacts and email preferences are each read once, and each refusal names its scope.
• WordPress. The Application Password is checked against your site, and the user it belongs to must be able to edit and publish posts. An account that can only write drafts is refused, with the missing capability named. The site address is needed for this check.
• Webflow and Notion. Beyond the token itself, the collection or database you entered is read. A Notion database not yet shared with the integration is refused with how to share it.
• PostHog. A one-row query runs against the project and region you entered, which is the same call the sync makes, so a key without query access to that project is refused.
• Microsoft Teams. The webhook address must be one Microsoft issues (an Incoming Webhook or a Workflow). We never post a test card to check it, because that would appear in your channel; the first real post confirms it.
• Gainsight. The card asks for your tenant address (the address you sign in to Gainsight at) next to the access key. The address must be a public https address. A one-row read on that tenant then refuses a bad or disabled access key, at connect and again when you reconnect with a new key, and a refused key never replaces the one already saved.

If HubSpot cannot be reached at that moment (an outage, a rate limit, a timeout), the token is saved anyway and the panel says the check did not complete. Their bad day should not stop you connecting, and the next scheduled poll records a real error on the card if the token does turn out to be wrong.

Where the output lands

Every run drafts first. Nothing goes out on your behalf. You choose where the drafts land:

• In-app draft queue. Drafts wait for your review here. Approve, edit, or skip each one.
• Google Drive. Turn on Drive delivery and each run also writes its report into your Drive "Accounts" folder as a Google Doc plus a raw .md copy, so you read it where you already work.
• Your mailbox as a draft. A drafted email lands in your own mailbox as a Gmail draft, ready for you to send. Writing a draft into your own mailbox is not an outbound send.

Alerting and admin-gated connectors

Two more kinds of connector sit alongside your CRM and mailbox:

• Collaboration: Slack and Microsoft Teams. Connect a Slack bot token or a Teams Incoming Webhook to post deal-risk flags and run summaries into your workspace. Both can carry an explicit approve or deny decision for supported work. Teams approvals also require the intended approver's Entra object ID, and every card links back to the same work in Sales as Code.
• Admin-gated: Gong. Gong API access is enabled by a Gong administrator, so it shows a connect your admin badge rather than a plain Connect button. Ask your Gong admin to approve the integration and enable API access, then connect. The same holds for other admin-enabled tools as they land.
• Renewing access. A connection that signs in with the provider renews its access in the background, the same way it first connected: a Salesforce sandbox renews against the sandbox, and Gong, Reddit and X send the app's credentials the way their sign-in requires. If a renewal is refused, the card says reconnect. If the provider's sign-in service is down, the renewal is tried again on the next sync and the card does not ask you to reconnect.

A proposed action approved in Slack uses the connection for the reviewed action itself. A Salesforce action uses Salesforce, for example. The approval and provider result are recorded separately. A rejected attempt can be tried again only when the provider confirms that nothing was applied. An uncertain result stays held for review. If Slack cannot update the original card, the decision and its application receipt still remain recorded.

A message in a Slack channel set up for desk triage files one ticket for each person listening on that channel. Slack sends a message again when it does not get an answer within three seconds, and triage often takes longer. The repeat is recognised and skipped, so it does not file a second ticket, run triage twice or post a second reply. A new message in the same thread is still filed.

An edit or a deletion in that channel reaches the copy we hold. An edited message is replaced with its new text, unless a newer change is already stored, so an edit delivered late never overwrites a later one. A deleted message is marked deleted and its text is no longer kept, in the stored message or in the desk ticket it filed: the ticket stays in the queue, closed and marked deleted in Slack, with its text and triage answer cleared. A precedent someone saved from that ticket is kept, since saving it was a choice to reuse the answer. Neither an edit nor a deletion files a new ticket or runs triage again.

A desk channel belongs to the Slack workspace you connected. Adding a channel asks Slack, with your own connection, whether the channel is in that workspace, and a channel from another workspace is refused. Messages, edits and deletions reach only people whose Slack connection is in the workspace the message came from.

When you install Slack, the permissions Slack granted are saved with the connection. If the install left one out (the app asks for chat:write, channels:history, app_mentions:read and commands), the card reads reconnect needed and names the missing ones. Reinstalling with all of them clears it. A Slack token that Slack reports as revoked or invalid is treated the same way.

Enterprise Salesforce access (behind SSO / Okta)

Okta gates the human login to the Salesforce UI, not the API. There are four rungs, and writes stay propose-and-apply on every one, never a silent write-back:

• OAuth Connected App. Per-user consent that redirects cleanly through Okta. The self-serve default, already wired.
• Admin-approved Connected App. An admin pre-authorizes the app and attaches a permission set, for locked orgs.
• JWT bearer. Server-to-server, no interactive login: the admin uploads a certificate once and the runtime exchanges a signed assertion for a token. For headless enterprise jobs. On the Salesforce card, choose Connect with a certificate and paste the connected app's consumer key, the username the app acts as, the login address (https://login.salesforce.com, https://test.salesforce.com for a sandbox, or your My Domain login address) and the private key that matches the certificate. We ask Salesforce for a token before saving anything, so a wrong key or a user the app is not approved for is refused on the spot with Salesforce's reason. The private key is stored encrypted and never shown again; every 10 minutes we sign a fresh request with it instead of using a refresh token. If Salesforce later refuses it (the certificate was replaced, or the user removed from the app), the card asks you to reconnect. If you switch to signing in, a renewal already under way cannot bring the certificate connection back: it only updates the access token while the stored connection is still that certificate. This path follows Salesforce's documented flow and has not yet been run against a live org.
• CSV / report export. The no-API fallback, and the only data-in path that needs no OAuth at all. Export your accounts, opportunities or contacts from Salesforce as CSV and upload them on the Connect page. Re-importing the same export updates in place rather than duplicating. See Importing a CRM report export below.

Imports write rows individually. If an import stops, its receipt reports the rows confirmed saved and whether the interruption happened while saving rows or updating workspace readers. A lost response leaves the result uncertain. Review your records before retrying the same file; matching record IDs update in place. The file stays selected for retry. Rows above the 5,000-row import limit are reported separately and need another import.

Importing a CRM report export

If your org will not grant API access at all, you do not need it. Export what you need from the CRM as CSV and upload it from the No API access? Import a CRM report export card on the Connect page. Pick whether the file holds opportunities, accounts or contacts, choose the file, and import. The columns each kind reads are listed under the control. The rows land in the same store the connectors fill, so every surface that reads your stored book works exactly as it would with a live connection.

This is data in only. Nothing here writes back to your CRM; a write back stays propose-and-apply on every path.

What the file needs

• An id column. Id, Opportunity ID, Account ID, Record ID and the 18-character variants are all recognised. A row with no id is skipped and counted, never guessed at, and the count is reported back to you.
• For accounts, a Domain or Website column if you have one. The domain is stored on the account, and an account whose domain matches a company research already found is linked to it both ways, so the company is researched once. A name never links, and nothing is merged or deleted.
• Whatever else your report carries. Column names are matched case and space insensitively against the ones the analytics read: stage, amount, close date, owner, industry, segment, lead source, competitor, region and loss reason for opportunities; ARR, renewal date, churn risk, status and the prior, renewed and expansion ARR figures for accounts. A money column can carry a currency symbol, thousands separators, or a parenthesised negative.
• Nothing else. Your original column headers are stored alongside, unchanged, so a stored row still reads the way your export did.

To update records already read from a connector, add a CRM Provider column with salesforce, hubspot, attio or pipedrive. Use the provider record ID in Account ID or Opportunity ID. The import uses the connector identity and qualifies opportunity account links the same way. Existing connector fields not supplied by the file remain intact, and discovery research stays in its own record. Names and domains never trigger a merge. Files without CRM Provider keep their existing bare-ID behavior; older bare-ID duplicates are not automatically combined.

Importing contacts

Choose Contacts (people) for a list of people. Each row needs an Email; a row without a valid address is skipped and counted. Name, Title, Company and Domain are optional. The email is the identity, so importing the same list again updates the same people rather than adding them twice, and a retry after an interrupted import writes the same records.

An imported person whose email matches someone research already found is linked to that person by exact email. Nobody is merged.

Add a Do Not Contact or Opt Out column to carry opt-outs across. A cell reading yes, true, y, 1 or x marks that person, and the exclusion policy then holds that exact address from research, contact selection and every send. Other people at the same company are not held. A later file that leaves the column blank does not lift the opt-out.

What you get back

The card reports how many rows were imported and how many were skipped. Those are different findings and it says which: a file where every row was skipped tells you the export is missing its id column, not that the import failed.

Importing is idempotent. Re-uploading the same export updates the same rows rather than creating duplicates, so a weekly report export is a reasonable habit.

An import that stops part way shows an Import receipt under the card: the last durable checkpoint (the record position and the ID of the last confirmed record), the first failed record with its ID and the reason, and the rows confirmed. The file stays selected. Retry from checkpoint sends the same file with that checkpoint, and the import writes from the failed record onward; the confirmed rows before it are not written again. The failed record is written again under the same record ID, so if its first write did land, the retry updates it rather than adding a second row. A different file, or one whose record at the checkpoint has another ID, is refused with nothing written; import the whole file again instead, which is always safe.

What it feeds

An imported book drives the stored-data side of attribution, win/loss, data quality, the Revenue Cockpit prefill, renewals, and deal inspection. Each of those tells you what it could not compute and why, so a partial export gives you the numbers it can support and a plain reason for the rest rather than a blank page.

Role-specific connectors and honest fallbacks

Each role has its own must-have tools. Where a vendor is open, you self-connect; where it is gated or closed, the badge says so and names the fallback:

• CSM: a Customer Success Platform (Planhat, or Gainsight behind connect-your-admin) federates CRM plus usage in one connection.
• Partner: Crossbeam for account overlaps and sourced pipeline.
• SE: a demo tool (Consensus) and an RFP tool (Responsive). RFP tools are import/export first, so Responsive is gated with an import fallback rather than promised as live sync.
• Data: Apollo and Cognism are the self-serve enrichment connectors. ZoomInfo is offered only to accounts that own the seat (enterprise-gated).
• LinkedIn Sales Navigator is CSV import only. The SNAP partner program is closed in 2026, so live sync is never promised; import your export instead.

Guided setup, /onboarding

Prefer to be walked through it? Get started is the guided version: three steps, one at a time. Add your AI provider key, connect your data (the same Connect your tools panel that is on this page), and choose where output goes. Then it hands you your console. Your progress through signup, the business record and the first connection is tracked on Home, not here.

How to use it

1. Hold a seat, from the pricing page. One seat licenses every role, and it is the whole price list.
2. Open Connect and link your CRM, inbox, and calendar in the managed-connectors panel. We custody each token encrypted and read it on a schedule.
3. Set your roles up: Get started takes your AI provider key and proposes the scheduled runs.
4. Choose where drafts land: the in-app queue, your Google Drive, or your mailbox as a draft.
5. As runs happen, run telemetry and brain state fill up. Watch Activity from your Home.

When the connector panel cannot load

A network failure or an expired session used to leave the managed-connector panel on "Loading connectors…" indefinitely. It now says what went wrong, offers a retry, and states plainly that a load failure is not the same as having no connections, so nothing about your connected tools has changed.

Turning managed connectors on or off tells you if the change did not save. The toggle springs back to where it was, which on its own would look like the click never registered.

Troubleshooting a connection

Each connector card on Connect carries its own state, and the states are the ones you can act on:

• Nothing connected, the runtime has nothing to read. Link a CRM, inbox, or calendar in the managed-connectors panel.
• Reconnect needed, a token was revoked or rotated at the provider, or the key it was stored under changed and we can no longer read it. The card says reconnect and names which tool.
• Degraded, one kind of record the connector reads failed or hit its per-poll read limit while the rest came back clean. The card names the record kind; re-reading the last few days after the cause is fixed recovers what that read missed.
• Error, a rate limit or a bad afternoon at the provider. It clears itself; you do not need to touch it.
• Entitlement mismatch, this account does not hold what a run needs (bought under a different email, or refunded). Runs stop at the entitlement check, and Settings shows you what the account holds.

This page used to carry a Diagnose panel that read the MCP audit log. Every fix it offered told you to set SALES_AS_CODE_API_KEY in an MCP client, which is not how anyone connects any more, so it was removed along with the four-step meter above it.

Manage your plan and billing

Settings opens on two panels. Your roles lists the roles this account holds, linking to Your roles for renewals, setup links and per-role rollups. What you own is the fuller ledger: each thing with its source and expiry, plus Subscription and the Stripe portal for invoices, payment method and cancellation. An account holding nothing yet is told what the seat costs rather than shown an empty list.

Team & seats

On a team plan, Team, Members lets the owner invite teammates up to the seat count. Each pending invite can be re-sent or shared as a direct copy-link if the email is missed, no need to contact support. Teammates accept with one click and their seat is covered by the team subscription.

Advanced: drive it yourself (API + MCP)

The default flow needs no key. If you want to run the account from your own scripts, a cron, or any MCP-compatible agent, issue a Bearer token under Settings, Advanced and point the client at the tenant-scoped MCP endpoint. Every skill verifies your licensed session first, then reads and writes the same store the product uses. Full detail: API Keys & MCP. This is a power-user option, not a requirement.

The Connection details card on Connect holds the two things that path needs: the MCP endpoint to point at, and how to authenticate. Both are the same whichever roles you hold, so there is one of each rather than one per role.

The work runs on our servers, so we process the data you connect. It is encrypted at rest, isolated to your tenant, never sold, and never used to train models, and you can revoke a connection at any time. Run telemetry is metadata; generated drafts hold content, and they stay in your account until you send them.

What has been verified against a live account

Connected means a token is saved. It does not mean every operation on that provider has been watched working against the vendor. Each integration below lists its operations and the evidence on record for each one. None recorded means nobody has yet run that operation against a live account, so check its first results before relying on it.

0 of 299 applicable operations verified against a live vendor. 75 built and not yet verified. 224 open. 25 not applicable. A row changes only when a person watches the operation work against the live vendor and records the date.

Related

• API Keys & MCP, the advanced path for power users who want to drive the account from their own client.
• Activity, the rollup of what your scheduled runs produced.
• Pricing: one seat, every role.