Skip to content

Add sources

Shipped

Your first source is connected during the setup wizard, and for most instances that source is Oracle NetSuite. This page covers adding more sources to an instance that’s already provisioned and set up.

Additional sources are an extension of the same canonical layer, not a separate system: a new source writes the same canonical tables in the same Postgres, under the same row-level security, and Atlas consolidates entities that appear in more than one of them.

Connectors take one of two console routes, and which one a source uses is a property of the connector, not something you choose.

Shared-app OAuth connectors — Jira, GitHub, Google Workspace, Asana, Notion, QuickBooks, Intercom, Ramp, Business Central, Workday, Zoho CRM, and Xero — connect on the console’s standalone connect-source page:

/instances/<slug>/connect-source/<source>

Every other source — NetSuite, Stripe, HubSpot, Shopify, Zendesk, Salesforce, Bill.com, Fireflies, GetSales, Granola, FeedHive, DocuSeal, PrintNode, WhatsApp Business, and Azure Blob Storage — connects through the setup wizard’s connect step, re-entered on your running instance:

/instances/<slug>/setup?source=<source>&new=1

That link renders the same connect form your first source used. You don’t normally type either address: the Add connection tiles in your app and the Reconnect button on a source both open the right one for you.

Connecting a source for the first time and adding a second connection of a source you already have are different links. A first connect is the address above. An additional connection carries an extra flag — ?new=1 on the connect-source route, &connection=new on the wizard route — because the two actions must not be confused: see More than one connection of the same source below.

The flow mirrors the first-source connect:

  1. Open the connect page for the source on your instance.
  2. For shared-app connectors, click Connect {Source} and Turbobase redirects you to the provider’s own consent screen, where you pick the workspace / account / company.
  3. The provider redirects back; the console completes the OAuth exchange (write-only into your instance’s secret store) and polls the connection to success.

A few connectors collect a little config first. For example, Business Central asks for your Entra tenant id and the BC environment before the OAuth redirect; the zero-input connectors render just the connect button.

The NetSuite card alone carries the Advanced settings → Data sync choice described in Connect your first source: leave it on to mirror records, turn it off to run NetSuite on customizations only. On every other connector, mirroring records is the whole connector, so connecting one starts the mirror and there is no switch to find.

More than one connection of the same source

Section titled “More than one connection of the same source”

You can connect many different sources to the same instance. You can also hold more than one connection of the same source: two NetSuite accounts, two QuickBooks companies, Stripe sub-accounts. Each is its own connection, with its own mirrored rows kept apart so records with the same internal id in two accounts are never merged into one.

Multiple connections of one source are enabled per instance: Turbobase staff turn it on for you, and until they have, a connected source’s tile offers no Add a connection affordance. Ask if you need it.

Adding a second connection is deliberately a different action from Reconnect. Reconnect re-authorises the account you already have; adding a connection brings on a new one. Use the source’s Reconnect button to re-authorise, and Add a connection to add. Pointing an existing connection at a different account would silently mix two accounts’ data.

Salesforce asks a little more of you than most sources, because the app your org signs in through is one you create. Read this before you start: the steps are short, but a missing setting shows up as a refused connection rather than as a prompt.

Which editions can connect. Enterprise, Unlimited, Performance and Developer edition orgs have API access and connect as they are. Professional and Group edition orgs do not have API access by default — Salesforce sells it as an add-on, and until it is on your org, a connection attempt is refused and says so. If you are not sure which you have, Salesforce shows it under Setup → Company Information.

Create the app Salesforce now asks for. In Setup, create a new External Client App with Distribution State Local, enable OAuth, and give it the callback URL the connect page shows you. Ask for the scopes the page lists (api and refresh_token, offline_access, plus the identity scope), leave PKCE and “require a secret” set to match what the page asks for, and under the app’s policies choose All users may self-authorize, a refresh-token policy of valid until revoked, and relax IP restrictions. Then copy the consumer key and secret into the connect page — Salesforce asks for a verification code before it shows them to you, and a brand-new app can take a few minutes to start working.

If you already have a working Connected App, its key and secret still connect. You only need an External Client App because Salesforce stopped allowing new Connected Apps to be created; it has not stopped the ones that exist.

Production or sandbox, and your My Domain. The connect page asks which you are connecting, and the choice is part of that connection rather than a setting on your instance — so you can hold a production org and a sandbox side by side as two connections. If your org uses a My Domain, give it on the same page (for example acme.my.salesforce.com); anything that is not a Salesforce host is refused there and then.

A sandbox needs its own app, every time it is refreshed. Salesforce does not copy a Local External Client App into a new or refreshed sandbox. So create one in each sandbox you connect, and expect to create it again after every sandbox refresh — a sandbox connection that stops working just after a refresh is almost always this.

Connect as a user who can see what you want mirrored. Salesforce’s own record-level sharing applies to the connection exactly as it applies to the person who made it, so a user who can only see their own opportunities mirrors only those. A dedicated integration user with API Enabled and View All Data is the usual choice. You are not stopped from connecting as a narrower user — the connection warns you instead, and your instance’s Health tab goes on naming anything the connection cannot read, so a half-mirrored table is never a mystery.

Your sign-in keeps itself alive. Salesforce sessions expire after a couple of hours of quiet, and Salesforce withdraws a connection’s permission to sign in again if 30 days pass without it being used. Your instance renews both on its own and shows you the date it last did. If the permission really has been withdrawn — someone revoked the app, the connecting user was deactivated — the Health tab says so in those words and Reconnect is the repair.

Xero connects as a shared-app OAuth grant on the connect-source page. Clicking Connect Xero sends you to Xero’s own consent screen, where you choose the organisation you want mirrored.

Three things are worth knowing before you connect it:

  • One connection holds one Xero organisation. Your login may administer several; the one you pick on the consent screen is the one this instance mirrors, and choosing a different organisation on a later reconnect is refused rather than silently switched. Re-consenting to the same organisation is how you repair a connection Xero has expired.
  • Turbobase only ever reads. It never creates, edits, voids or deletes anything in your Xero organisation. The connection is one-way by design, not by configuration — there is no setting that changes it.
  • Contacts, invoices, bills, credit notes, payments, purchase orders, bank transactions, manual journals, your chart of accounts, your items and your cost-tracking categories are mirrored, and they land in the same tables as everything else you have connected. Your tracking categories come across twice over: each line names the option it is tagged with, and the options themselves become rows you can list and count — one row per option, with the category it belongs to on every one of them. An option you have archived in Xero is still there, marked inactive, so an older line that uses it still makes sense.

Changes to contacts and invoices arrive within moments; everything else refreshes on a schedule, so allow up to four hours for a new payment or bank transaction to appear.

GitHub connects as a shared-app OAuth grant on the connect-source page. There is nothing to type: clicking Connect GitHub sends you to GitHub’s own install screen, where you pick the account or organisation and which repositories Turbobase may see.

Three things are worth knowing before you connect it:

  • The repositories you pick are the whole of what is mirrored. Issues and their comments, pull requests and their reviews, labels, milestones, boards and cards, discussions, workflow runs and the files behind them come in for the repositories on that install screen, and for no others. Narrow or widen the selection on GitHub and the connection follows it.
  • Changes arrive as they happen. GitHub signs the calls it makes to your instance, so an issue opened or a run finished is in your database moments later rather than on a four-hour schedule.
  • Turbobase reads until writing is switched on. Opening an issue, editing one, moving its labels, replying on an issue, a pull request or a discussion, committing a file onto a branch behind a pull request, and starting a workflow that offers a manual run are all built — and all held shut until Turbobase staff turn writing on for your instance. Nothing is ever re-run, cancelled, approved or deleted on your behalf.

Google Workspace connects as a shared-app OAuth grant on the connect-source page, and what it brings in is your shared drives. There is nothing to type: you approve on Google’s own consent screen with an ordinary sign-in.

A shared drive belongs to your organisation rather than to a person, so one connect reads the same documents whoever made it. Gmail, personal My Drive and Calendar are not part of this connector — reaching those would need a grant over your whole domain, and Turbobase does not ask for one.

Once it is connected, the instance’s Shared drives screen in the console is where you say which drives to mirror, and it is not an optional setting: a connection with nothing picked reads nothing at all. The screen lists the shared drives the connect found and you tick the ones you want; a drive you have not ticked is never read, and un-ticking one stops it. Documents, spreadsheets, slides and the other files on a ticked drive land alongside your other knowledge sources, with their text read out so the assistant can answer from what they say.

If a shared drive was created after you connected, it won’t be on the list yet — the list is what the connect saw. Reconnect the source and the new drive appears for you to tick.

New and changed files arrive as they happen — Google calls out to your instance when a drive changes. The connection only ever reads: nothing Turbobase does creates, edits or deletes a file in your Google Workspace.

PrintNode connects with an API key rather than an OAuth redirect, and it is the shortest connect in the product: the key is the whole of what you type. Find it in PrintNode under your account’s API keys, then paste it into the PrintNode step of the wizard.

Three things are worth knowing before you connect it:

  • It is a printing connector, not a records one. The printers you already have — and the computers they are attached to — are mirrored into your instance so that an automation can name one. Your app lists them on Data → Synced records; expand the printer row to find a printer’s id.
  • Printing is the write, and it starts off. A print job raised in Turbobase is sent out through PrintNode and paper comes out of your own printer. Because that cannot be undone, sending is a separate per-instance setting Turbobase staff enable on request. Until then the connection only reads.
  • A job says how it ended. PrintNode answers when it has accepted a job rather than when the page is printed, so Turbobase follows the job up and settles it on the row. A job still reading as sent has not printed yet.

FeedHive connects with an API key rather than an OAuth redirect. Find it in FeedHive under Settings → Account → API Key, then paste it into the FeedHive step of the wizard.

Three things are worth knowing before you connect it:

  • Turbobase only reads until publishing is switched on. Out of the box it never creates, schedules or edits a post in your FeedHive account. Publishing is a separate per-instance setting that Turbobase staff enable on request, so the connection stays one-way until you ask for it to be otherwise. Even with it on, Turbobase never deletes a post.
  • New posts appear within about four hours, not instantly. FeedHive can call out when a post publishes, but it offers no way to prove such a call really came from FeedHive — so Turbobase declines to accept them and refreshes on its own schedule instead.
  • Your posts land alongside your other knowledge sources, not in a table of their own, so the assistant can answer questions about what your company has said publicly, when, and on which channel. A post published to several social accounts at once is stored once, not once per account.

DocuSeal connects with an API token rather than an OAuth redirect. Find it in DocuSeal under Settings → API, then paste it into the DocuSeal step of the wizard.

Four things are worth knowing before you connect it:

  • Say which DocuSeal cloud your account is on. DocuSeal runs two — docuseal.com (US) and docuseal.eu (EU) — and a token issued in one is not valid in the other. The wizard defaults to the US cloud, which is what you get if you never chose. Picking the wrong one looks exactly like a bad token, so it is worth checking rather than guessing.
  • A self-hosted DocuSeal cannot be connected. Only the two published clouds are accepted.
  • Turbobase reads by default, and only reads. Your signature requests, the people they were sent to and the templates behind them are mirrored into your instance. Sending a request from Turbobase is a separate switch that starts off — ask us to turn it on once you have seen the connection working. Nothing leaves your DocuSeal account until you do.
  • The webhook secret is optional, and skipping it costs freshness. If you set one in DocuSeal (Settings → Webhooks, pointed at your instance), signatures show up in Turbobase as they happen. Without it, Turbobase refuses deliveries it cannot verify and refreshes on its own schedule instead. You can add it later.

WhatsApp Business connects by signing in to Meta in a popup and choosing the WhatsApp Business account to connect — there is nothing to find and paste. If your business has several accounts, connect each one; they stay separate on your instance, and a phone number in one is never confused with the same number in another.

Five things are worth knowing before you connect it:

  • Conversations become records, not a screen. The person you are talking to is a contact, the thread is a conversation, and every message is an activity row beside everything else your instance knows about that person — so a customer’s WhatsApp history sits next to their orders and their invoices. Turbobase does not add an inbox or a chat view, now or later: reading conversations and replying are things an app built on your instance does, over its API.
  • Who answers a number decides who can read it. Each business number can be assigned to a person or a role through your instance’s API, and that assignment is what controls visibility: the person it names reads that number’s conversations, nobody else does, and a number nobody answers is readable by administrators only. Administrators read everything. The assignment is yours alone — it is never sent to Meta.
  • Sending starts off, and WhatsApp decides what may be sent. A reply raised in Turbobase goes out under your own verified business name and cannot be withdrawn, so sending is a separate per-instance setting Turbobase staff enable on request. Once it is on, two of WhatsApp’s own rules apply: you may send ordinary text only within 24 hours of the customer’s last message, and outside that window only a template WhatsApp has approved. Both are checked before anything leaves your instance, so a refused send costs nothing and says what to send instead.
  • Meta bills you for messages, not us. Per-message charges go to your own WhatsApp Business account on the payment method you hold with Meta. They do not come through Turbobase and do not appear on your Turbobase invoice.
  • History before the connection does not arrive. WhatsApp publishes no way to read past messages, so your instance mirrors conversations from the moment the account is connected onward. The same is true of anything sent from the WhatsApp Business phone app on a number you also use there.

Azure Blob Storage connects with a Microsoft Entra application rather than an OAuth redirect. In the Azure portal, register an application under Microsoft Entra ID → App registrations, give it a client secret, and grant it the Storage Blob Data Reader role on the container you want mirrored — or Storage Blob Data Contributor if you also want Turbobase to be able to add files. Then paste the directory (tenant) id, the application (client) id and the client secret into the Azure Blob Storage step of the wizard, along with your storage account name and the container.

Five things are worth knowing before you connect it:

  • One connection holds one container. Not one storage account — one container inside it. If you keep documents in two containers, connect each as its own connection; nothing Turbobase does to one can reach the other.
  • Choose how the files are kept, and the choice is yours to make. Copied brings each file into your instance, so reading one never depends on Azure being reachable and never costs you egress again. Left in Azure keeps only a pointer, so you store nothing twice and pay egress each time somebody opens a file. The wizard asks and does not pick for you, because the right answer depends on your bill rather than on your data.
  • Either way the assistant can answer from what your files say. Text is read out of a file when it is mirrored, whichever mode you chose, so leaving the files in Azure saves you storage without costing you search. Your documents land alongside your other knowledge sources, not in a table of their own.
  • Turbobase only reads until you ask for more. Adding files is a separate per-instance setting that Turbobase staff enable on request, so the connection stays one-way until you ask. When it is on it covers the whole connected container, at any folder depth — there is no narrower scope to pick, so connect a container you are content for Turbobase to write into. Removing a file is built but not yet available by any route.
  • Writing needs a container Azure can undo. A write to blob storage is immediate and has no review step, so Turbobase refuses to write at all unless the account has blob versioning or blob soft delete turned on. It is checked when you connect, and again before anything would be overwritten. If neither is on, the connect is refused and tells you which to enable.

New and changed files appear within about four hours rather than instantly: Azure can be made to call out when a blob changes, but that is a subscription you would create and pay for in your own Azure account, so Turbobase refreshes on its own schedule instead.

A connection’s life doesn’t end at connecting it. The instance’s Connections screen in the console lists every connection you hold, one row each, and carries three actions: pause one, which stops it syncing in both directions; resume it again; and remove it, which deletes the records it brought in. + Add a connection is on the same screen, for a source that holds more than one.

Pausing is the reversible one, and it changes nothing you already have. A paused connection stops being polled and its webhook deliveries are discarded, so no new records come in — and nothing goes the other way either: a change you make in Turbobase to a record that came from a paused connection is refused, with a message telling you the connection is paused, rather than being accepted and silently never sent. Everything already mirrored into your instance stays exactly as it is, and your apps, your reports and your queries carry on reading it. Resume it whenever you like and it picks up from where the source is then, and changes start flowing back again. Pause acts on one connection: if you hold two NetSuite accounts you can pause one and leave the other syncing.

Your app shows a paused connection as Paused on its Sources row, so a connection that has gone quiet doesn’t read as a broken sync.

Pausing is not the same as turning data sync off. The data sync choice is made once, per source, at connect time, and it can only be turned on — it decides whether a mirror exists at all, and app surfaces start depending on that mirror the moment it does. Pause is the other switch: per connection, and always reversible.

Removing a connection deletes the records it brought in, permanently. There is no undo and no backup. Every mirrored row that came from that connection goes, along with the connection itself; a consolidated customer that only that connection knew about goes with it, and one that another connection also knows about stays. The console asks you to type the connection’s name before it will proceed, and offers pause as the non-destructive alternative in the same dialog.

Re-connecting the same account afterwards starts a fresh, empty backfill — it does not bring the old rows back.

Removing a connection does not revoke your other connections’ access: the stored credentials for a source are only cleared when its last connection is removed.

Adding a source to a live instance is enabled per instance and per connector: Turbobase staff turn a connector on for your instance. If a source isn’t enabled for you yet, the connect page surfaces a contact path instead of the connect button. Reach out if you need a connector turned on.

A newly connected source starts mirroring into your instance’s database. Watch it sync and confirm health from your app’s source health view, and browse the new data through your data model. New sync volume shows up in Billing and usage.