FastSpring

FastSpring is a merchant of record and e-commerce platform that handles payments, subscriptions, taxes, and invoicing for software and SaaS businesses.

Bruin supports FastSpring as a source for Ingestr assets. You can ingest data from FastSpring into your data platform.

To set up a FastSpring connection, add a configuration item in the .bruin.yml file and in your asset file. You authenticate with your API username and password, created under Developer Tools > APIs > API Credentials in the FastSpring app.

Follow these steps to set up FastSpring and run ingestion.

Configuration

Step 1: Add a connection to the .bruin.yml file

connections:
  fastspring:
    - name: "fastspring"
      username: "your-api-username"
      password: "your-api-password"

• username: (Required) FastSpring API username.
• password: (Required) FastSpring API password.

Step 2: Create an asset file for data ingestion

Create an asset configuration file (e.g., fastspring_ingestion.yml) inside the assets folder with the following content:

name: public.fastspring
type: ingestr

parameters:
  source_connection: fastspring
  source_table: 'orders'

  destination: postgres

• name: The name of the asset.
• type: Always ingestr for FastSpring.
• source_connection: The FastSpring connection name defined in .bruin.yml.
• source_table: Name of the FastSpring table to ingest.
• destination: The destination connection name.

Available Source Tables

Table	PK	Inc Key	Inc Strategy	Details
orders	id	changed	merge	Orders and their line items, payments, taxes, and returns. Supports date-range filtering.
subscriptions	id	changed	merge	Recurring subscriptions, including status, billing period, and pricing. Supports date-range filtering.
accounts	id		replace	Customer accounts, including contact details and address.
products	id		replace	Products in your catalog, including pricing and fulfillment settings.
coupons	id		replace	Coupons and their discount configuration.
subscription_report	subscription_id, transaction_date (default)	sync_date	merge	Subscription metrics (MRR, ARR, subscribers, churn) grouped by the fields you choose.
revenue_report	order_id, transaction_date (default)	syncdate	merge	Revenue metrics grouped by the fields you choose.

orders and subscriptions support incremental date-range loads: the run's date interval — set with --start-date / --end-date (see run) — filters records to that window. The subscription_report and revenue_report tables have configurable columns and grouping — see Reports below.

Step 3: Run asset to ingest data

bruin run assets/fastspring_ingestion.yml

Running this command ingests data from FastSpring into your Postgres database.

Reports

FastSpring's Data API can generate aggregated subscription and revenue reports:

Table	Details
subscription_report	Subscription metrics (MRR, ARR, subscribers, churn, …) grouped by the fields you choose.
revenue_report	Revenue metrics grouped by the fields you choose.

Each report has sensible default columns and grouping. To customize, set source_table to the colon form <report>:<columns>:<group_by>, where columns and group_by are comma-separated lists. Omit a part to keep its default:

• subscription_report: default columns and grouping.
• subscription_report:mrr,arr,subscription_id,transaction_date: custom columns, default grouping.
• revenue_report:income_in_usd,product_name:product_name,transaction_month: custom columns and grouping.

For example:

name: public.revenue_report
type: ingestr

parameters:
  source_connection: fastspring
  source_table: 'revenue_report:income_in_usd,product_name:product_name,transaction_month'
  destination: postgres

See the subscription report and revenue report references for the full list of columns.

The group_by fields become the table's primary key, so they must uniquely identify a row.

Incremental behavior

Reports load incrementally (merge) using the sync date as the incremental key: sync_date for subscription_report and syncdate for revenue_report. Each run sends its start date as the report's sync-date filter, so only rows synced on or after that date are pulled, and results are upserted on the group_by primary key without duplicates. The sync-date column is always requested, even when you pass a custom columns list, so incremental sync keeps working regardless of the columns you choose.