​
Database & Entities

Swiftgum uses a relational schema to manage workspaces, integrations, tokens, and user sessions. This design enforces secure and scalable storage of credentials, session data, and more. Below is a high-level view of how tables connect to each other.

Encryption & Credentials Sensitive fields—like API keys and OAuth tokens—are stored in an encrypted format, often leveraging a dedicated vault or encryption layer. This ensures that even if the database is accessed, the credentials remain secure.

​
Entity Relationship Overview

diagram

Note

The above diagram is a simplified representation. It doesn’t show every column or constraint but highlights the core relationships.

How It All Ties Together

Workspace

Each developer or company sets up a workspace. They configure integrations (with providers) to enable OAuth for end users.

Providers & Integrations

  • A single Provider can serve multiple Integrations (e.g., dev vs. prod).
  • Each Integration has encrypted_credentials (client secrets, etc.).

End Users & Tokens

  • End users link personal accounts.
  • Swiftgum stores their OAuth tokens in the Tokens table, ensuring each token is encrypted and bound to a single workspace + integration.

Sessions

  • Auth Sessions handle the in-progress OAuth flow.
  • Portal Sessions let an end user temporarily access the Swiftgum portal UI to manage their connections.

Destinations

Where processed or extracted data gets written (e.g., Supabase or local Postgres). Also stored securely, with connection info in encrypted_destination_config.

Queue Ingestions

Tracks new or updated documents for ingestion. The Engine processes these items into a normalized format or embeddings.

By splitting data across these entities, Swiftgum ensures secure, scalable, and modular handling of user data, credentials, and ingestion flows.