Source kinds

Select Data Sources lists every kind Atlas can connect to. They fall into four families, and the family tells you what the form will ask for: a connection URL, a structured credential, a file from your Vault, or an account you've already connected to Futurity.

Every kind is read-only: Atlas opens the connection, reads structure and rows, and closes it again.

Databases

Connected by a standard connection URL, plus a Test connection button that opens a real connection before you save anything. Each field carries a line under its label saying what goes in it and which options the URL accepts.

Warehouses

Business systems

ERPs and CRMs with no SQL surface. Atlas reads them through their own APIs, so the credential is whatever that vendor issues. Each field names the page of the vendor's console the value is copied from and links that vendor's own documentation.

Dynamics 365 pins each source to one legal entity — the Company field is "the dataAreaId every query is pinned to — one legal entity per source. For multiple companies, connect one source per company."

Files and spreadsheets

The four file kinds read from your Vault. The form lets you either drop a file in — it lands in the Vault — or browse to one that's already there. Uploads are capped at 50 MB per file.

Pick more than one file and the name field disappears: Atlas makes one source per file, named after the file, and shows you the mapping before you submit.

CSV and Excel files are read as a table, not as a grid of cells, so Atlas works out where the table starts and where it ends. A trailing row whose first cell is a totals label (Total, Totals, Subtotal:, Gesamt, and the equivalents in the other languages it recognizes) is dropped, so summing that column doesn't count the sheet's own total a second time. A cell that merely begins with one of those words, Total Recall in a film list, is data and stays. Where the end of the table had to be guessed, Atlas also drops a last row that looks like a footer by shape, a lone value in a wide row or a mostly empty one; where the end was detected outright, those rows are kept.

When a file can't be read, the reason comes back in words rather than as a generic failure, both on screen and to Corint: a CSV whose delimiter, quoting or column count doesn't hold up, a file larger than Atlas will read, or an .xlsx whose contents expand far past what the file itself declares, which is refused as corrupt or malicious. The message names the thing to check, so a file that can never parse doesn't get retried as though it might.

A file source is copied at discovery, not read live — which is why replacing the file means running discovery again to pick up the new version.

Connected accounts

Salesforce and Google Sheets bind to an account you connect, rather than to a credential you paste. The form has a Connect button that runs the provider's normal sign-in, and only offers the source once an account is attached. Google Sheets then wants the spreadsheet's link or ID, with a Test access button that confirms the sheet is reachable.

Both kinds are listed in Select Data Sources whether or not the provider is wired up in your Futurity instance — you find that out inside the form. Where the Account section would be, an unavailable provider says so instead: "This provider isn't available in your workspace yet."

External connectors

A third-party service that speaks the Atlas connector protocol, rather than a database or a vendor API Atlas knows first-hand. The External Connector card is on for every organization; an administrator can switch the Atlas External Connectors feature off per organization, which hides the kind and makes the API refuse it.

If you're the integrator building the service, Build an Atlas connector covers the protocol end to end.

The base URL is wherever the connector answers, path and all: Atlas reads <base>/.well-known/futurity/atlas.json and calls every endpoint under that same prefix, so one host can serve several connectors at different paths.

The token is the bearer the connector's integrator issued you, and must be at least 32 characters. Read connector fetches the connector's public capability document (atlas.json), confirms the base URL points at a real connector, and renders one input per credential the connector asks for. Those are your own upstream credentials, not the integrator's: the same hosted connector serves every customer, and each one types their own. Changing the base URL clears the document and anything typed against it.

Test connection then sends the token and those credentials to the connector's /check. Green means both were accepted upstream; a rejection shows the connector's own message, so a wrong password reads as the upstream's complaint about it rather than a generic failure.

Pick an icon from the searchable list to represent the connector across Atlas; it defaults to a plug and is the only source kind whose icon you choose.

Atlas caches that capability document when you connect. Rebind on an active connector re-reads it and takes a fresh set of credentials, which is how you pick up a connector that has changed the entities or fields it exposes, or a credential that has rotated.

Right after you register or rebind a connector, Atlas runs its live conformance program in the background and the status chip reads verifying. When it finishes the chip moves to conformant or failed conformance, and on a failure the chip's tooltip carries the first failing check. A rebind runs the program again.

Where to go next