Creating Data Connections

A connection is a secure, read-only bridge between your data source and Spartera. Once connected, you can create analytics assets that run against your data — without your raw data ever leaving your infrastructure.

Before You Start

Choose which database you're connecting — see Supported Data Sources
Create a dedicated read-only user or service account for Spartera — never use admin credentials
Whitelist Spartera's IP in your firewall: 34.70.197.249 (production) / 34.57.29.87 (staging)
Gather your credentials — see Credential Formats for exact JSON structures per platform
Review minimum required permissions — see Connection Permissions

Creating a Connection

Via the Seller Dashboard

app.spartera.com → Connections → New Connection

Select your platform, enter credentials, fill in all required fields, and click Save. Then click Test Connection to verify everything works before building assets on top of it.

Via API

from spartera_api_sdk.api import connections_api
import json

connections = connections_api.ConnectionsApi(client)

connection = connections.companies_company_id_connections_post(
    company_id,
    {
        "company_id": "your-company-id",
        "user_id": "your-user-id",
        "engine_id": 1,
        "name": "Production BigQuery",
        "description": "Main analytics warehouse — updated daily at 2 AM UTC",
        "provider_domain": "yourcompany.com",
        "credential_type": "SERVICE_ACCOUNT",
        "credentials": json.dumps(your_credentials_dict),
        "verified_usage_ability": True
    }
)

Use GET /companies/{company_id}/cloud-providers for a live list of supported engines and their IDs.

Required Fields

Field	Description	Example
`name`	Unique, descriptive name. Letters, numbers, spaces, `-`, `_` only. Min 3 chars.	`Production BigQuery`
`description`	What data this connection contains. No quotes allowed.	`Customer analytics warehouse, refreshed daily`
`engine_id`	The database platform — see engine ID table below	`1`
`provider_domain`	The domain where this data originates — see below	`yourcompany.com`
`credential_type`	Auth method for this platform	`SERVICE_ACCOUNT`
`credentials`	Your credentials (encrypted at rest)	See Credential Formats
`verified_usage_ability`	Confirm you have the right to use and share this data	`true`

Provider Domain

The provider_domain field tells Spartera — and marketplace buyers — where this data comes from and who owns it. This is important for marketplace trust and data provenance.

First-party data — you own this data. Set provider_domain to your company's domain.

yourcompany.com

Third-party data — you have licensed this data from another source and are reselling insights from it. Set provider_domain to the original data owner's domain.

data.provider.com

Being accurate here matters. Buyers on the marketplace can see the data source — misrepresenting provenance violates marketplace terms.

Engine IDs

These are the platforms currently live on Spartera. Each row is a supported connection type.

Google Cloud Platform

Platform	Engine ID	Default Credential Type
BigQuery	`1`	`SERVICE_ACCOUNT`
Cloud SQL (MySQL)	`3`	`SERVICE_ACCOUNT`
Cloud SQL (PostgreSQL)	`28`	`SERVICE_ACCOUNT`

Amazon Web Services

Platform	Engine ID	Default Credential Type
Redshift	`4`	`ACCESS_KEY`
Redshift Serverless	`9`	`ACCESS_KEY`
RDS MySQL	`5`	`ACCESS_KEY`
Aurora Serverless	`25`	`ACCESS_KEY`
Aurora Provisioned (MySQL)	`26`	`ACCESS_KEY`
Aurora Provisioned (PostgreSQL)	`27`	`ACCESS_KEY`

Microsoft / Self-Hosted

Platform	Engine ID	Default Credential Type
SQL Server	`16`	`CLIENT_SECRET` (Azure) / `JSON` (self-hosted)

Multi-Cloud & Database Platforms

Platform	Engine ID	Default Credential Type
Snowflake	`15`	`USERNAME_PASSWORD`
Teradata Vantage	`17`	`USERNAME_PASSWORD`
Supabase (PostgreSQL)	`23`	`JSON`
Supabase Analytics	`24`	`API_KEY`
Databricks SQL	`29`	`JSON`
Databricks Model Serving	`30`	`API_KEY`

External & Data APIs

Platform	Engine ID	Default Credential Type
External / Data API	`20`	`API_KEY`

External API Connections

External API connections (engine ID 20) link Spartera to an HTTPS API. They serve two purposes, chosen with the API Type field on the connection:

Managed Calculation (STRUCTURED) — Spartera calls your API to compute a single value (such as an ML model prediction) and sells it as a Calculation asset. Your model and logic stay on your infrastructure.
Data Feed Passthrough (PASSTHROUGH) — Spartera calls a data API, repackages the response into rows you configure, and resells it as a Data endpoint. Ideal for value-added reselling of third-party data APIs.

The API Type determines what the connection can back: Managed Calculation → assets; Data Feed Passthrough → endpoints.

See External API Connections for the full setup guide, including required fields, authentication options (including Bearer tokens), IP whitelisting, and response format requirements.

Testing Your Connection

After saving, click Test Connection to verify Spartera can reach and authenticate with your database. The test returns one of three statuses:

SUCCESS — All connection capabilities verified. Spartera can connect, authenticate, query, and access your schema.

PARTIAL — Connection partially successful. Some capabilities may be limited. Review the recommendations in the test result to resolve specific issues.

FAILED — Connection failed. The test result includes specific error messages and recommendations.

Error	Likely Cause	Fix
Connection timeout	Firewall blocking Spartera	Whitelist `34.70.197.249`
Authentication failed	Wrong credentials or format	Check Credential Formats
Permission denied	Insufficient database privileges	Review Connection Permissions
SSL error	Certificate or TLS version issue	Enable TLS 1.2+; verify cert validity
Invalid credentials JSON	Malformed JSON	Validate your JSON before uploading

Platform-Specific Notes

SQL Server

Self-hosted SQL Server connections use ODBC Driver 18 for SQL Server — configured automatically by the backend. You do not need to specify the driver in your credentials. See Connection Permissions for Azure-hosted vs self-hosted permission differences.

Databricks SQL

The access token inherits all permissions of the generating user. Always create a dedicated service principal with minimum permissions: CAN USE on one SQL Warehouse, SELECT on specific schemas only.

Supabase Analytics

Prefer the anon key with Row Level Security (RLS) policies configured over the service role key. Only use the service role key if RLS is in place and validated.

Connection Naming Best Practices

Good	Why
`Production BigQuery — Sales & Marketing`	Source + environment + domain
`Snowflake — Customer360 Warehouse`	Source + specific purpose
`Redshift Staging — ETL Testing`	Source + environment + use

Avoid	Why
`My Connection`	Ambiguous
`BQ1`	Not descriptive
`Test`	Doesn't say what or where

Managing Connections

# List all connections
curl https://api.spartera.com/companies/{company_id}/connections \
  -H "x-api-key: your-api-key"

# Update a connection
curl -X PATCH https://api.spartera.com/companies/{company_id}/connections/{connection_id} \
  -H "x-api-key: your-api-key" \
  -H "Content-Type: application/json" \
  -d '{"name": "Updated Connection Name"}'

# Delete a connection (fails if active assets depend on it)
curl -X DELETE https://api.spartera.com/companies/{company_id}/connections/{connection_id} \
  -H "x-api-key: your-api-key"

Credential Formats Reference — Exact JSON structure for every platform
Connection Permissions Reference — Minimum IAM roles and database grants per platform
External API Connections — Connecting ML models and prediction APIs
Supported Data Sources — Platform overview and requirements