Skip to main content

Common Schema

Common Schemas are data models developed and maintained by Supaglue to make it easier to integrate with multiple providers within the same category. Supaglue maintains a common schema for each category, and maps each third-party provider API to its respective common schema(s). Common schemas can be used for both reads and writes, through managed syncs and via the unified API.

common schemacommon schema

Common Object​

Each Common Schema consists of a set of Common Objects that map to provider objects and fields across all providers within a category. For example, the Accounts common object in CRM maps to Salesforce Accounts and HubSpot Companies. Common Objects have a 1-N relationship between your application and provider objects.

Configuration​

In the Management Portal, go to Syncs --> Sync Config. Under Common Objects select the objects you want to sync.

common object sync configcommon object sync config

Upon a customer going through their Oauth flow using an Embedded Link, Supaglue will create a Connection and start syncing the configured Common Objects to your Destination.

Object names​

Supaglue defines Common Object names using lowercase letters with snake casing. E.g. account and sequence_state for the Engagement category.

info

Object names are singular.

Table names​

Tables are named using lowercase letters with snake casing in the following format: ${Category}_${Common Object name}s, e.g. engagement_accounts.

info

Table names are plural.

Table schemas​

Supaglue lands three categories of data in your Destination:

  1. Supaglue metadata fields: These specify the application, customer, provider, and timestamps associated with the managed sync.
  2. Unified data (common schema fields): This is the unified common object data model and stored in the _supaglue_unified_data column. You can hoisted to top-level table columns using generated columns in postgres or (materialized) views in BigQuery.
  3. Provider-specific raw data: The raw third-party Provider data. We pass these through as-is. This is stored in the raw_data (will be renamed to _supaglue_raw_data in the next release.) column (jsonb). If the unified data doesn't contain the fields you need, you can use the raw data to access the provider-specific fields directly, or hoist them using generated columsn or views just like you would for _supaglue_unified_data.

Below is an example schema for the crm_accounts table:

postgres=> \d crm_accounts
                              Table "production.crm_accounts"
          Column          |              Type              | Collation | Nullable | Default
--------------------------+--------------------------------+-----------+----------+---------
 _supaglue_application_id | text                           |           | not null |
 _supaglue_provider_name  | text                           |           | not null |
 _supaglue_customer_id    | text                           |           | not null |
 _supaglue_emitted_at     | timestamp(3) without time zone |           | not null |
 _supaglue_unified_data   | jsonb                          |           | not null |
 raw_data                 | jsonb                          |           | not null |
 id                       | text                           |           | not null |
Indexes:
    "crm_accounts_pkey" PRIMARY KEY, btree (_supaglue_application_id, _supaglue_provider_name, _supaglue_customer_id, id)

{/ TODO: add supaglue prefix to raw_data and maybe id fields, to be consistent esp with provider objects /}

info

Please note that Supaglue metadata fields differ slightly between Common Objects and Provider-specific Objects.

Writing​

Use Supaglue's Unified APIs to write to Common Objects.

Common schema definitions​