Linking Campfire as a source
This source is currently in alpha. The interface and available tables may change.
The Campfire connector syncs your accounting data from Campfire into PostHog: general ledger transactions, journal entries, invoices, bills, payments, bank activity, revenue recognition contracts, and company objects like vendors and the chart of accounts. This lets you analyze your financial data alongside your product data.
Prerequisites
You need an active Campfire account with access to create API users and keys (Settings > API keys).
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 Campfire, you'll need an API key:
- In Campfire, go to the API keys page (Settings > API keys).
- Click Create User to create a dedicated API user. A
view onlyrole is enough, since PostHog only reads data. - Click Create API Key on the new API user and copy the key. It's only shown once.
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.
Tables where Campfire supports server-side filtering by modification time (like GL transactions, bills, payments, vendors, and contracts) can sync incrementally on last_modified_at. The other tables sync with a full refresh.
Configuration
| Option | Type | Required |
|---|---|---|
API key | password | Yes |
Supported tables
| Table | Description | Sync method | Incremental field | Primary key |
|---|---|---|---|---|
chart_transactions | General-ledger transactions (ChartTransaction records) - Campfire's GL transaction log and the recommended endpoint for row-level GL data. Each transaction carries account, department, vendor, entity, and journal/date metadata. | Incremental, Full refresh | last_modified_at | — |
journal_entries | Journal entries with their transactions, account information, vendor and department details, tag associations, attachments, and exchange rate data for multi-currency entries. | Full refresh | — | — |
invoices | Accounts receivable invoices, including line items, payment status, client and entity relationships, and totals. | Full refresh | — | — |
invoice_payments | Payments applied against accounts receivable invoices. Voided payments are included with voided_date set, so payments reversed after a previous sync can be detected. | Incremental, Full refresh | last_modified_at | — |
credit_memos | Accounts receivable credit memos, including line items, application status (open, partially used, used, voided), and client relationships. | Full refresh | — | — |
bills | Accounts payable bills with vendor, entity, currency, aging, and payment status information, including calculated totals, amounts paid, and amounts due. | Incremental, Full refresh | last_modified_at | — |
bill_payments | Payments applied against accounts payable bills. Voided payments are included with voided_date set, so payments reversed after a previous sync can be detected. | Incremental, Full refresh | last_modified_at | — |
debit_memos | Accounts payable debit memos, including line items, status, and vendor relationships. | Full refresh | — | — |
bank_accounts | Bank accounts with balances, currency, institution details, and their mapping to chart of accounts types. | Incremental, Full refresh | last_modified_at | — |
bank_transactions | Bank transactions from connected bank accounts. | Full refresh | — | — |
vendors | Vendors and customers, including contact details, parent vendor metadata, and the full lineage of ancestor vendors so parent/child relationships can be reconstructed. | Incremental, Full refresh | last_modified_at | — |
departments | Departments, including parent department metadata so parent/child relationships can be reconstructed. | Incremental, Full refresh | last_modified_at | — |
chart_of_accounts | The chart of accounts (GL accounts). Each account includes metadata about its parent account and its full lineage, so parent/child account relationships can be reconstructed. | Full refresh | — | — |
contracts | Revenue recognition contracts. | Incremental, Full refresh | last_modified_at | — |
revenue_transactions | Revenue transactions used for revenue recognition. | Incremental, Full refresh | last_modified_at | — |
Troubleshooting
If a sync fails with an authentication error, the API key may have been revoked or the API user's role changed. Create a new API key in Campfire and update the source credentials in PostHog.
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.