Skip to main content
A data source is anything you connect once and let Deyta Platform sync from continuously. Once configured, files and rows from the source are pulled in, run through the same remember pipeline as direct ingestion, and surface as memories in the chosen namespace. Three categories of source are supported:

Object stores

S3 (and S3-compatible endpoints). Files in a bucket are ingested as memories.

Data warehouses

Snowflake. Rows from configured queries are ingested.

OAuth integrations

Google Drive and other providers. End users authorize via OAuth; their content syncs into the namespace.
Direct ingestion via remember from your application is covered in the Quickstart. Most production deployments combine both — direct API for live events, data sources for backfill and ongoing sync.

​
Two surfaces in the console

The console splits the lifecycle across two pages:
PageWhat it’s for
IntegrationsBrowse available providers and start a new connection (OAuth or manual).
ConnectionsSee and manage every live data source connection across your org — pause, resume, test, delete.
You’ll create connections in Integrations and revisit them in Connections.

​
Object stores

Configure once with bucket credentials. Deyta Platform reads files matching a prefix and ingests their contents.

​
From the console

Open Connections in the sidebar, choose Object store, and provide:
FieldValue
NameFriendly label
NamespaceWhich namespace the synced content lands in
ProviderCurrently s3 (S3 and S3-compatible endpoints)
Access key ID / secret access keyIAM credentials with read access to the bucket
BucketThe bucket name
RegionAWS region
PrefixOptional. Limits sync to keys under this prefix.
EndpointOptional. For S3-compatible providers (MinIO, R2, etc.).
Use a least-privilege IAM user — read-only on the bucket and prefix, nothing else. The credentials are stored encrypted, but smaller blast radius is always better.
After creating the connection, the first sync runs in the background. Subsequent runs pick up new and modified objects.

​
Lifecycle

Object store connections support pause and resume from the console. Pausing stops new sync runs without disconnecting; resuming picks up where it left off. The test action is available both before creation (with inline credentials) and on an existing connection — useful for confirming that a credential rotation succeeded.

​
Data warehouses (Snowflake)

Configure a Snowflake connection at the organization level and Deyta Platform can ingest from any namespace’s configured queries.

​
From the console

Open Data warehouses in the sidebar, click Add connection, and provide:
FieldValue
NameFriendly label
AccountSnowflake account identifier (e.g., xy12345.us-east-1)
WarehouseCompute warehouse to run queries against
DatabaseDefault database
SchemaDefault schema
Username / passwordService account credentials
Unlike object store connections, Snowflake connections are org-scoped, not namespace-scoped. The same connection can drive ingestion into multiple namespaces, each with its own query configuration.
Once the connection is live, configure per-namespace ingestion jobs that point at specific tables or queries. Sync runs on a schedule and on-demand.

​
OAuth integrations

For consumer-cloud sources (Google Drive, etc.), the user authorizes Deyta Platform against their own account via OAuth. Your application drives the flow with the gateway integrations API. The full flow:
1

List enabled providers

Call GET /integrations/list to see which providers your org has enabled.
2

Start a connect session

Call POST /integrations/connections/start with the namespace and provider key. Deyta Platform returns a session token and an OAuth redirect URL.
3

User authorizes

Use the @nangohq/frontend SDK to walk the user through the provider’s OAuth screen. The provider returns a token to your callback.
4

Complete the session

Call POST /integrations/connections/complete with the OAuth callback values. The connection is now live and sync starts.
import { Deyta } from "@deyta-ai/sdk";

const deyta = new Deyta({ apiKey: process.env.DEYTA_API_KEY! });
const ns = deyta.namespaces.scope("ns_…");

const session = await ns.integrations.start({ provider: "google_drive" });
// session.session_token  →  pass to @nangohq/frontend
// session.auth_link_url  →  redirect URL

// …after the user completes OAuth in the browser…

await ns.integrations.complete({
  id: session.id,
  token: oauthToken,            // from Nango callback
  account_id: nangoAccountId,   // from Nango callback
  connection_id: nangoConnId,   // from Nango callback
  provider: "google_drive",
});
Once complete, the integration runs continuously in the background. Files added to the user’s drive (or whatever the source is) appear as memories in the namespace within minutes.

​
Listing and removing connections

const connections = await ns.integrations.list();

await ns.integrations.delete(connectionId);
Deleting a connection stops sync and removes the local record. The upstream provider connection is not revoked — the user has to revoke it from the provider’s account settings if they want to fully cut off access.

​
Provider availability

Which providers are usable in your org is controlled by the Integrators section under Admin. An admin can toggle providers on or off; disabled providers don’t appear in the integrations UI and start calls return 403.

​
What’s next

Querying memories

Use recall and ask against the memories you’ve ingested.

Managing memories

Inspect, audit, and forget memories.