Which direction does data move between FreshBooks and Airbase?

The main flow is Airbase into FreshBooks. Approved vendor bills and their vendors move from Airbase into FreshBooks as bill vendors and AP bills. Bill payments recorded in FreshBooks are reflected back to Airbase so its payment status matches, while Airbase card transactions and GL accounts stay read-only and are not written back.

How does the integration handle the two different auth models?

Airbase uses a long-lived bearer token generated in its portal against a tenant-specific base URL, and FreshBooks uses OAuth2 with the authorization-code grant tied to a specific user. ml-connector stores both encrypted, refreshes the FreshBooks access token on a 401 and saves the rotated refresh token, and tracks the Airbase token because it has no automatic refresh and must be rotated manually.

Why does the connector poll instead of relying on webhooks?

FreshBooks does send HMAC-signed webhooks, but it states delivery latency is not guaranteed and can range from seconds to minutes, so they are not a reliable trigger for payables. Airbase webhooks exist but the signing scheme is not publicly documented and bills only matter once approval clears. ml-connector therefore polls both sides on a schedule, paging FreshBooks at its 100-record limit.

FreshBooksAirbase

FreshBooks and Airbase integration

FreshBooks runs invoicing and accounting for small businesses. Airbase, now Paylocity Finance, runs accounts payable, corporate cards, and expense management. Connecting the two keeps the vendor bills approved in Airbase in agreement with the accounting ledger in FreshBooks, without re-keying. Vendors and AP bills flow from Airbase into FreshBooks once they clear approval, and bill payments recorded in FreshBooks flow back so Airbase reflects what has settled. ml-connector handles the different APIs and auth models on each side and moves the data on a schedule you control.

How FreshBooks works

FreshBooks exposes clients, invoices, bill vendors, AP bills, invoice and bill payments, expenses, the chart of accounts, and journal entries through its REST accounting API at api.freshbooks.com. It authenticates with OAuth2 using the authorization-code grant, so every token represents a specific user who granted consent, and there is no client-credentials option. Almost every path needs either the accountId for accounting endpoints or the numeric businessId for time-tracking, both fetched from the identity endpoint after OAuth. FreshBooks supports outbound webhooks signed with HMAC-SHA256, but delivery latency is not guaranteed, so reliable syncs read by polling with page and per_page, capped at 100 records per page.

How Airbase works

Airbase exposes vendors, AP bills, purchase orders, payments, expense reimbursements, card transactions, GL accounts, and subsidiaries through its REST spend API. It authenticates with a long-lived bearer token generated inside the Airbase portal, passed in the Authorization header, and the base URL is tenant-specific because the platform is multi-tenant. The API reference is customer-gated, so pagination style, rate limits, and idempotency support are confirmed only inside the portal. Airbase supports outbound webhooks for events such as approval milestones, but the signing scheme is not publicly documented. Bills, POs, and expenses pass through configurable approval chains, so a record exists before it is approved or paid.

What moves between them

The main flow runs from Airbase into FreshBooks. As vendor bills clear their approval chain in Airbase, ml-connector reads the bill and its vendor and writes them into FreshBooks, creating the bill vendor first and then the AP bill against it. Vendor master records are aligned in both directions so contact and tax details stay consistent. After a bill is paid in FreshBooks, the bill payment is read and reflected back to Airbase so its payment status matches the ledger. GL accounts are aligned so each FreshBooks bill posts to an account that already exists. Card transactions and GL accounts in Airbase are read-only, so ml-connector never writes those back.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Airbase side it sends the portal bearer token against the tenant-specific base URL captured per customer, and it tracks token age because there is no refresh flow and rotation is manual in the portal. On the FreshBooks side it runs the OAuth authorization-code flow, refreshes the access token when a call returns 401, and stores the new refresh token each time since FreshBooks invalidates the previous one. Because Airbase approval timing and FreshBooks webhook latency are both unreliable as triggers, it polls each side on a schedule, paging FreshBooks at 100 records per request. An Airbase vendor maps to a FreshBooks bill vendor, and an Airbase bill maps to a FreshBooks AP bill, which always requires a vendorid, so the vendor is created or matched before the bill. New bills are written with a stable bill_number so retries do not create duplicates, since FreshBooks documents no idempotency key. FreshBooks soft-deletes by setting vis_state rather than issuing HTTP DELETE, so removals are reflected as state changes, not hard deletes. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A 60-person digital marketing agency bills clients in FreshBooks and runs its vendor payments, contractor expenses, and corporate cards through Airbase. Before the integration, the bookkeeper approved subcontractor and software vendor bills in Airbase, then re-entered each one into FreshBooks by hand to keep the books current, and reconciled payment status across the two tools at month-end. With FreshBooks and Airbase connected, every approved Airbase bill lands in FreshBooks as an AP bill against the right vendor, and payments recorded in FreshBooks flow back so Airbase shows what is settled. The duplicate data entry is gone and the payables in both systems agree.

What you can do

Write approved Airbase vendor bills into FreshBooks as AP bills, creating the bill vendor first.
Keep vendor master records aligned across Airbase and FreshBooks so contact and tax details match.
Reflect FreshBooks bill payments back to Airbase so its payment status tracks the ledger.
Bridge the Airbase portal bearer token and the FreshBooks OAuth user token, refreshing FreshBooks tokens automatically.
Poll each side on a schedule with retries, idempotent bill numbers, and a full audit trail on every record.

Questions

Which direction does data move between FreshBooks and Airbase?: The main flow is Airbase into FreshBooks. Approved vendor bills and their vendors move from Airbase into FreshBooks as bill vendors and AP bills. Bill payments recorded in FreshBooks are reflected back to Airbase so its payment status matches, while Airbase card transactions and GL accounts stay read-only and are not written back.
How does the integration handle the two different auth models?: Airbase uses a long-lived bearer token generated in its portal against a tenant-specific base URL, and FreshBooks uses OAuth2 with the authorization-code grant tied to a specific user. ml-connector stores both encrypted, refreshes the FreshBooks access token on a 401 and saves the rotated refresh token, and tracks the Airbase token because it has no automatic refresh and must be rotated manually.
Why does the connector poll instead of relying on webhooks?: FreshBooks does send HMAC-signed webhooks, but it states delivery latency is not guaranteed and can range from seconds to minutes, so they are not a reliable trigger for payables. Airbase webhooks exist but the signing scheme is not publicly documented and bills only matter once approval clears. ml-connector therefore polls both sides on a schedule, paging FreshBooks at its 100-record limit.

Connect FreshBooks and Airbase

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started