Skip to main content

Connect the data you already have

Connectors for Airtable, Google Sheets, SQL databases, and CSV upload, plus a custom REST API for anything else. Read-only at generation time. Available on every plan, including Free.

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

SourceToDocs connects to five data sources — Airtable, Google Sheets, SQL databases, CSV upload, and a custom REST API — and all five are available on every plan, including Free.

Native data sources. Connectors built specifically for systems where structured content tends to live: Airtable, Google Sheets, and SQL databases. These are the most common starting points. The connector handles schema discovery so a non-technical user can map fields without writing SQL.

CSV upload. When your data lives in a one-off export rather than a live system, upload a CSV and map its columns to template placeholders — no connector setup required.

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. The same REST API works with n8n, Make, Zapier, or anything that speaks HTTP.

How it works

Wiring a data source happens once per source, not once per template:

  1. Authorize the connector (OAuth, API key, or database credentials, depending on the source).
  2. The platform introspects the source and shows available fields, tables, or endpoints.
  3. Pick the subset relevant to the documents you want to generate. The platform builds an internal schema.
  4. 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 clauses, REST API query parameters), 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.

Get Started →

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 account workflows. A QBR deck that pulls account history, product usage signals, and open opportunities from Airtable or a SQL database — or from your CRM through its REST API. The deck is generated when the CSM clicks a button or when a scheduled job fires — both work.

Data teams driving reporting from a SQL database. A monthly executive report that runs a parameterized SQL query, then produces a branded slide deck or PDF. The query lives in the database 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 Airtable AND a SQL database in the same document, you either pre-join upstream 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 that data also lives in a SQL database elsewhere — 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 a SQL database for billing records, 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 SQL databases — 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.

Related reading