Linking Wasabi as a source
This source is currently in alpha. The interface and available tables may change.
The Wasabi connector syncs sub-account, usage, and billing data from the Wasabi Account Control API (WACA) into PostHog – sub-accounts, daily storage and data-transfer utilizations (account-level and per-bucket), and sub-account invoices. Use it to track storage spend and usage per sub-account or bucket alongside your product and revenue data.
This connector talks to the Account Control API for Wasabi Control Accounts (partners managing sub-accounts). It does not read objects from your Wasabi buckets – to import files stored in Wasabi, use the S3-compatible bucket options on our S3 source instead.
Prerequisites
You need a Wasabi Control Account with Wasabi Account Control API access enabled, and a WACA API key. API access is enabled by Wasabi on request – contact Wasabi Sales if it isn't active on your account yet.
Adding a data source
- In PostHog, go to the Sources tab of the data pipeline section.
- Click + New source and click Link next to this source.
- Enter your credentials (see Configuration below) and click Next.
- Select the tables you want to sync, choose a sync method and frequency, then click Import.
Once the syncs are complete, you can start querying this data in PostHog.
When linking Wasabi, you'll need an API key: generate one from your Wasabi Control Account following Wasabi's guide to generating an Account Control API key.
Sync modes
Each table can be synced in one of several modes, depending on what the source supports:
- Webhook (when available) – the source pushes changes to PostHog in real time. Fastest freshness, lowest ongoing cost, and the only mode that reliably captures updates and deletes.
- Incremental – only new or updated rows are synced on each run, using a cursor field (such as an
updated_attimestamp). Cheaper than a full refresh, but deletes aren't captured. - Append only – new rows are appended using a cursor field; existing rows are never updated. Ideal for immutable, append-only tables like event logs.
- Full refresh – the whole table is reloaded on every sync. Use it when a table has no reliable cursor or when you need deletions reflected.
See sync methods for a full explanation of how each mode works and how to choose between them.
The utilizations and bucket_utilizations tables support incremental syncs on StartTime – Wasabi computes utilization metrics daily, so each incremental run only fetches days at or after the last synced day. The accounts and sub_account_invoices tables are full refresh.
Configuration
| Option | Type | Required |
|---|---|---|
API key | password | Yes |
Supported tables
| Table | Description | Sync method | Incremental field | Primary key |
|---|---|---|---|---|
accounts | Sub-accounts associated with the Wasabi Control Account, with summary profile information. | Full refresh | — | — |
utilizations | Daily storage and data-transfer utilization for the Control Account and each sub-account, across all buckets. | Incremental, Full refresh | StartTime | — |
bucket_utilizations | Daily utilization for the Control Account and sub-accounts, broken down into per-bucket components. | Incremental, Full refresh | StartTime | — |
sub_account_invoices | Sub-invoices for each sub-account. Sub-invoices across all sub-accounts are rolled up into a single invoice charged to the Control Account. | Full refresh | — | — |
Troubleshooting
If syncs fail with a permissions error, check that Wasabi Account Control API access is enabled on your Control Account and that the API key is still valid – Wasabi returns a 403 Forbidden response for invalid or revoked keys.
If your sync is failing or data looks wrong, see the Data warehouse troubleshooting guide. If that doesn't help, contact support – we're happy to help.