Which direction does data move between Wave Accounting and BigCommerce?

The main flow is BigCommerce into Wave Accounting. Orders become Wave invoices, shoppers become Wave customers, and catalog products are aligned to Wave products and services. Refunds recorded in BigCommerce are reflected against the matching Wave invoice, and ml-connector does not push accounting entries back into the store.

How does the integration deal with BigCommerce webhook payloads that only carry an id?

BigCommerce webhooks deliver a stub with just the resource type and id. ml-connector first verifies the HMAC-SHA256 signature in the X-BC-Signature header, then calls the REST orders endpoint to fetch the full order before writing anything to Wave. A scheduled poll backfills any order a webhook missed, since BigCommerce can auto-deactivate a webhook after repeated delivery failures.

What does the Wave Pro subscription requirement mean for this connection?

As of 2026, a third-party app can only access a Wave business that holds an active Wave Pro subscription, and free-tier businesses fail authorization or return permission errors. ml-connector confirms the subscription during OAuth onboarding and surfaces a clear message if it is missing. It also uses the offline_access refresh token to renew the roughly two-hour Wave access token so syncs do not break mid-run.

Wave AccountingBigCommerce

Wave Accounting and BigCommerce integration

Wave Accounting handles invoicing and bookkeeping for small businesses. BigCommerce runs the online store and records every sale. Connecting the two means each BigCommerce order becomes a Wave invoice without re-keying, and the people and products on both sides stay in agreement. ml-connector handles the very different APIs on each side, a GraphQL service on Wave and a REST store on BigCommerce, and moves the records on the cadence you set.

How Wave Accounting works

Wave Accounting exposes customers, invoices, products and services, chart-of-accounts entries, and money transactions through a single GraphQL endpoint at gql.waveapps.com. It authenticates with a 3-legged OAuth2 authorization-code flow, and access tokens expire after about two hours unless the offline_access scope is granted for a refresh token. Every query and mutation is scoped to a businessId that ml-connector retrieves first through the businesses query. Wave can also push invoice, customer, payment, product, and transaction webhooks signed with HMAC-SHA256. The connected Wave business must hold an active Wave Pro subscription for third-party access. Wave has no purchase order, structured AP bill, or payroll objects in this API.

How BigCommerce works

BigCommerce is an e-commerce platform, not an ERP, so it has no chart of accounts, vendor records, or purchase orders. It exposes orders through the REST v2 API and order transactions and refunds through v3, plus customers and catalog products. A connector authenticates with a store-level API account, sending a pre-generated static access token in the X-Auth-Token header against a store_hash-specific base URL. BigCommerce pushes order, customer, and product webhooks signed with an HMAC-SHA256 digest in the X-BC-Signature header, but each payload is only a stub carrying the resource type and id, so the full record must be fetched over REST.

What moves between them

The main flow runs from BigCommerce into Wave Accounting. When an order is placed or updated in BigCommerce, ml-connector creates or refreshes the matching invoice in Wave, with line items mapped from the order products and totals carried across. New BigCommerce shoppers are created as Wave customers, and catalog products are aligned to Wave products and services so invoice lines reference items that already exist. Refunds recorded in BigCommerce are reflected against the related Wave invoice. The cadence is event-driven from BigCommerce webhooks, with a scheduled poll that backfills any order a webhook missed.

How ml-connector handles it

ml-connector stores both credential sets encrypted and sends the BigCommerce X-Auth-Token on every REST call against the store_hash base URL, while refreshing the Wave OAuth2 access token before its roughly two-hour expiry using the offline_access refresh token rather than waiting for a 401. On startup it runs the Wave businesses query once and scopes every GraphQL mutation to that businessId. BigCommerce webhooks arrive signed with an HMAC-SHA256 digest in the X-BC-Signature header and carry only a resource id, so each is verified, then the full order is fetched with GET on the v2 orders endpoint before anything is written. Because Wave webhooks fire with HTTP 200 even on GraphQL errors, ml-connector always checks the errors array in the response body, not just the status code. Customers and products are aligned first so each invoice line references a customer and a Wave product that exist. Wave invoices are created, approved, and sent rather than patched, so an existing invoice is matched before a duplicate is made, and the Wave Pro subscription is confirmed during onboarding. BigCommerce returns HTTP 429 when the per-window rate limit is hit, so ml-connector reads the reset header and backs off, and every record carries an audit trail and can be replayed if a Wave write fails.

A real-world example

A small home-goods retailer with about fifteen staff sells through a BigCommerce store and keeps its books in Wave Accounting because the accounting tier is free. Before the integration, a bookkeeper exported the week's orders from BigCommerce and hand-entered each sale into Wave as an invoice, then matched refunds line by line at month-end, which left revenue lagging the store by days and invited typos. With Wave Accounting and BigCommerce connected, every order becomes a Wave invoice as it is placed, customers and products stay aligned, and refunds flow through to the right invoice. The bookkeeper reviews rather than re-keys, and the books reflect the store in near real time.

What you can do

Turn each BigCommerce order into a Wave Accounting invoice with line items mapped from the order products.
Create BigCommerce shoppers as Wave customers and align catalog products to Wave products and services.
Reflect BigCommerce refunds against the matching Wave invoice so the books stay current.
Bridge the BigCommerce X-Auth-Token and the Wave OAuth2 session, scoping every write to the Wave businessId.
Run event-driven from verified BigCommerce webhooks with a scheduled backfill poll, retries, and a full audit trail.

Questions

Which direction does data move between Wave Accounting and BigCommerce?: The main flow is BigCommerce into Wave Accounting. Orders become Wave invoices, shoppers become Wave customers, and catalog products are aligned to Wave products and services. Refunds recorded in BigCommerce are reflected against the matching Wave invoice, and ml-connector does not push accounting entries back into the store.
How does the integration deal with BigCommerce webhook payloads that only carry an id?: BigCommerce webhooks deliver a stub with just the resource type and id. ml-connector first verifies the HMAC-SHA256 signature in the X-BC-Signature header, then calls the REST orders endpoint to fetch the full order before writing anything to Wave. A scheduled poll backfills any order a webhook missed, since BigCommerce can auto-deactivate a webhook after repeated delivery failures.
What does the Wave Pro subscription requirement mean for this connection?: As of 2026, a third-party app can only access a Wave business that holds an active Wave Pro subscription, and free-tier businesses fail authorization or return permission errors. ml-connector confirms the subscription during OAuth onboarding and surfaces a clear message if it is missing. It also uses the offline_access refresh token to renew the roughly two-hour Wave access token so syncs do not break mid-run.

Connect Wave Accounting and BigCommerce

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

Get started