Connect the data you already have
Native connectors for Airtable, Sheets, Notion, Postgres, MySQL. CRM connectors for Salesforce, HubSpot, Pipedrive. Warehouse connectors for BigQuery, Snowflake, Redshift. Custom REST API support.
Document automation only matters if it can read your real data. Not a flat CSV export, not a manually maintained spreadsheet — the live source where your team already manages the content. SourceToDocs connects to that source, reads what it needs at generation time, and never modifies it.
The connector layer is built around two ideas. First, your data already lives somewhere and the document tool’s job is to fit into your stack, not the other way around. Second, generating a document should never carry the risk of corrupting the data it was generated from — every connector is strictly read-only at generation time.
What it does
The platform pulls data from one of three connector families, plus a custom escape hatch when none of them fit.
Native data sources. Connectors built specifically for systems where structured content tends to live: Airtable, Google Sheets, Notion, Postgres, MySQL. These are the most common starting points for teams who haven’t yet built a warehouse. The connector handles schema discovery so a non-technical user can map fields without writing SQL.
CRM connectors. Salesforce, HubSpot, Pipedrive. These are for workflows where the document being generated is downstream of customer data — QBRs, account reports, renewal briefings, proposals. The connector authenticates against your CRM, reads the records relevant to the generation, and respects the field-level permissions of the connecting user.
Warehouse connectors. BigQuery, Snowflake, Redshift. These are for teams who have already centralized their data and want to drive document generation from analytical queries rather than transactional systems. Query results bind into the template the same way Airtable records do.
Custom REST API. When the source isn’t on the list, the platform can pull JSON from any REST endpoint with standard auth (Bearer token, OAuth 2.0). You define the shape of the response you expect, the platform maps it to template placeholders. This is the escape hatch that turns “we have to integrate first” into a 30-minute configuration.
How it works
Wiring a data source happens once per source, not once per template:
- Authorize the connector (OAuth, API key, or database credentials, depending on the source).
- The platform introspects the source and shows available fields, tables, or endpoints.
- Pick the subset relevant to the documents you want to generate. The platform builds an internal schema.
- Map placeholders in your template to fields in the schema.
After that, every generation against that template uses the most current data in the source — pulled at generation time, not cached. If a speaker confirms a session in Airtable at 4pm, a program generated at 4:01pm reflects the change.
What’s included
- Read-only by design. The platform never writes back to a source. There is no edit flow, no field update, no record creation. This is enforced at the connector level — even an administrator can’t make the platform write to a connected system.
- Schema discovery. Available fields are surfaced in the UI so the person mapping placeholders doesn’t need to know the schema by heart or query the source directly.
- Field-level filtering. When the data source supports filtering (Airtable views, SQL
WHERE, CRM queries), the platform passes filters through so you can scope generation to a subset of records. Generate the QBR deck for one account, not all accounts. - Authentication that respects your security model. OAuth connectors use the connecting user’s permissions. Database connectors use the credentials you configure. The platform doesn’t ask for “admin access” when read-only access is enough.
- Schema versioning. When a source schema changes (a column rename, a new field), the platform surfaces the diff so you can update mappings deliberately rather than discovering breakage on the next generation.
Where it fits
Operations teams who already standardized on Airtable. Sessions, speakers, accounts, properties, projects — Airtable is often the source of truth long before there’s a warehouse. The Airtable connector is the most mature integration we offer. For a deeper walk-through, see airtable document automation.
Customer success and sales teams running CRM-driven workflows. A QBR deck that pulls account history, product usage signals, and open opportunities from Salesforce or HubSpot. The deck is generated when the CSM clicks a button or when a CRM field changes — both work.
Data teams driving reporting from a warehouse. A monthly executive report that runs a parameterized BigQuery or Snowflake query, then produces a branded slide deck or PDF. The query lives in the warehouse where the data team can version it; the platform consumes the result.
Teams whose source isn’t on the list. The custom REST API connector means “no connector for that system” rarely blocks a project. If the system has an API, we can read from it.
Honest limits
- No real-time or streaming sources. We pull at generation time. A source that produces millions of events per second isn’t a fit unless you’ve already aggregated it into a queryable system.
- Sources behind a VPN or on-premises require an inbound tunnel. We don’t provide hosted tunneling — you bring your own (a self-hosted reverse proxy or a tool like Tailscale).
- No multi-source joins inside a single template (today). One template binds to one source bundle. If you need data from Salesforce AND BigQuery in the same document, you either pre-join in the warehouse or expose a custom REST endpoint that does the join.
- No write-back. This is intentional, but worth saying explicitly: if your workflow requires updating a source system based on a generated document (marking a record as “report sent”), you’ll handle that in your own automation layer.
FAQ
Which connector should I start with?
Whichever system the data is actually in. Most teams overthink this. If your sessions/accounts/properties already live in Airtable, the Airtable connector is the right answer even if you also have a warehouse — start with the source closest to your operators.
Can I use more than one source per workspace?
Yes. Each template is bound to one source bundle, but a workspace can have many templates each connected to different sources. A consulting firm might use Airtable for client lists and HubSpot for contacts, with different templates pointing at each.
What if my source has 200 fields and I only need 10?
You map only what the template uses. Unmapped fields are ignored. There’s no cost to having a source with many fields you don’t currently bind to — it gives you room to extend templates later without re-wiring the connector.
Can I bring my own database connection string?
For Postgres, MySQL, and the supported warehouses — yes. You provide credentials and connection details, the platform stores them encrypted, and uses them only at generation time. We recommend a read-only database user with the minimum required permissions.
How does authentication work for OAuth connectors?
OAuth flows are initiated from the platform UI. You authorize the SourceToDocs application on the source side; tokens are stored encrypted and refreshed automatically. Revoking access from the source side immediately disables the connector — no separate offboarding step required.