Skip to main content

​
Overview

Stigg’s integration with BigQuery allows you to export your product catalog, customer, and subscription data directly to your BigQuery project for custom reporting and analysis.
Stigg’s native data export integrations are included in the Scale plan, and are also available as an optional add-on to the Growth plan. See Stigg’s pricing for more details.

View the full entity schema

See every table and column exported to your destination, organized by entity group.

​
Setting up the integration

This guide describes the current connect flow. If your BigQuery connect form instead asks for an HMAC Key Access ID, HMAC Key Secret, and a Service Account Key JSON rather than an auth method and service account email, your account hasn’t moved to this flow yet — contact Stigg support rather than following the steps below.

​
Prerequisites

  • A Google Cloud project with billing enabled.
  • Permission to create service accounts and edit IAM policies in that project (Owner, or Service Account Admin + Project IAM Admin).
  • Access to the Stigg dashboard with permission to configure integrations.
The connect form offers three authentication methods. This guide covers IAM Role, the recommended one — you create a service account in your own Google Cloud project and grant Stigg’s data-syncing account permission to impersonate it via short-lived tokens, so no key file or long-lived secret ever leaves your project. For Key Auth and Federated OAuth, see Other authentication methods below.
1

Enable the required APIs

In APIs & Services → Library, enable:
  • BigQuery API (bigquery.googleapis.com)
  • Cloud Storage API (storage.googleapis.com)
  • IAM Service Account Credentials API (iamcredentials.googleapis.com)
The third one is easy to miss and is required — it’s what issues the short-lived tokens used for impersonation. Without it, the connection fails even when every role is correct.
2

Create the destination dataset

In BigQuery → your project → Create dataset, set a Dataset ID and pick a location — write it down, since the staging bucket in the next step must match it exactly.
3

Create the staging bucket

BigQuery has no built-in staging area, so data is first written to a Cloud Storage bucket and then bulk-loaded into BigQuery. Files are deleted after each transfer — nothing is retained.In Cloud Storage → Buckets → Create:
  • Location type must match the dataset location from the previous step. If the dataset is in the US multi-region, choose Multi-region → us.
  • Enforce public access prevention — leave enabled.
  • Access control — Uniform.
The bucket location can’t be changed after creation. If it doesn’t match the dataset, the connection may pass but transfers will fail on load, and the bucket has to be recreated.
The bucket must use a Google-managed encryption key (the default). Bucket encryption with customer-managed encryption keys (CMEK) isn’t currently supported.
4

Create the destination service account and grant it access

This is the account that does the actual work inside your project. In IAM & Admin → Service Accounts → Create service account, name it something recognizable, e.g. stigg-prequel. Its email will be stigg-prequel@<PROJECT_ID>.iam.gserviceaccount.com.Don’t create a key for it — keys aren’t used by this method (the IAM Role method covered in this guide). Then grant it:BigQuery Job User must be granted at the project level — the bigquery.jobs.create permission can’t be granted on a dataset. Granting only dataset-level access is the most common cause of failure after impersonation itself.
For the dataset grant, use BigQuery → your dataset → Sharing → Permissions → Add principal, with the service account as principal and BigQuery Data Owner as the role.
If you’d rather have Prequel create the dataset for you instead of pre-creating it, grant BigQuery User at the project level instead of BigQuery Job User.
5

Allow Stigg to impersonate the service account

This is the step the whole integration hinges on, and it’s granted on the service account, not on the project.In IAM & Admin → Service Accounts, open the service account from the previous step, go to Principals with access → Grant access, and add Stigg’s data-syncing account:
Grant it both:
  • Service Account Token Creator
  • Service Account User
The most common mistake is granting these roles on the project instead of on the service account itself — these are two different screens in the Google Cloud Console, and a project-level grant silently does nothing for this integration. Verify with gcloud iam service-accounts get-iam-policy $SA --project=<PROJECT_ID> — the output must list both roles for the datasync account.
6

Fill in the Stigg connect form

In Stigg, navigate to Integrations → Apps → BigQuery and provide:
Don’t confuse the two service-account fields: Provider service account email is Stigg’s, while Service account email is the one you created for this integration. The staging bucket fields ask only for a name and a region — no access key or secret is required, since the bucket is accessed by the same impersonated service account.
Click Test & continue. If the check passes, the integration is connected.
7

Choose entities to export

Expand the Entities to export section to choose which entity groups to include in the sync. All groups are selected by default.See Exported entities for a description of each group.Click Connect to complete the setup.

​
Other authentication methods

The connect form’s Auth method dropdown offers two further options besides IAM Role.

​
Key Auth

Instead of impersonation, you hand over a service account key file. Use this only if your organization’s policy rules out cross-project impersonation — it places a long-lived credential outside your project, which is why both Google and Prequel recommend against it. The dataset, staging bucket, and service account setup above still apply, but you don’t need to grant Stigg’s account impersonation access. Instead, create a key for the service account:
  1. In IAM & Admin → Service Accounts, open the service account and go to Keys → Add key → Create new key.
  2. Choose key type JSON and create it. The file downloads once and can’t be re-downloaded.
Then fill in the connect form: Project ID, dataset, bucket name and region are the same as for IAM Role. Delete the local copy of the key file once it’s submitted, and rotate the key periodically from IAM & Admin → Service Accounts → Keys.

​
Federated OAuth

For customers who run Workload Identity Federation and want access to originate from their own identity provider rather than a Google-to-Google grant, BigQuery also supports connecting via Federated OAuth. Setup involves configuring a Workload Identity Federation pool in GCP and an OAuth client in your identity provider. This method hasn’t been run end-to-end by Stigg yet, so we’re setting it up hands-on rather than publishing self-serve steps. Contact Stigg support to configure Federated OAuth for your BigQuery destination.

Related topics

Exported entitiesSync process, schedule, manual sync, and sync history