How to Export BigCommerce Orders to MongoDB

Store BigCommerce order data in MongoDB for flexible analytics and reporting.

What This Integration Does

BigCommerce's reporting is fine for dashboards inside the platform, but the moment you want to join orders with marketing spend, warehouse data, or your own customer model, you need a copy of the orders outside BigCommerce. MongoDB is a natural fit: orders are nested documents, the shape evolves over time, and your analysts will want to query freely without sticking to a fixed schema.

The workflow runs on a schedule, pulls orders updated since the last run, normalizes them lightly, and upserts them into a MongoDB collection. Because BigCommerce order IDs are stable, re-running a sync window is safe: the same order gets overwritten in place, not duplicated.

Prerequisites

A BigCommerce connection with read access to the Orders API (V2 store_v2_orders_read scope or equivalent).
A MongoDB connection (Atlas or self-hosted) with write access to your target database.
A target database (e.g. bc_mirror) and a collection per entity (orders, customers, products).

Step 1: Schedule Trigger

Drop a Trigger node and set its type to Schedule. Schedule triggers use a 5-field Unix cron expression plus an IANA timezone, so */15 * * * * with Australia/Sydney runs every 15 minutes; hourly (0 * * * *) is plenty for most stores under a few thousand orders a day. The trigger output is {{ scheduledAt }}, which the next step uses to anchor the sync window.

Step 2: Transform - Compute the Sync Window

Add a Transform node to derive the window from the trigger. Use the date connector's subtract tool to step back from {{ scheduledAt }} by your schedule interval (plus a small overlap), and expose two values:

syncStart - {{ scheduledAt }} minus the interval, so each run picks up everything modified since the previous tick.
syncEnd - {{ scheduledAt }}, the upper bound of this window.

BigCommerce's min_date_modified filter is inclusive, so a few minutes of overlap with the previous window is fine: the upsert in the final step makes re-processing the same order harmless.

Step 3: Fetch Orders from BigCommerce

Add a Connector node pointing at the bigcommerce connector and pick the list-orders tool. Configure:

min_date_modified: {{ syncStart }}
max_date_modified: {{ syncEnd }}
limit: 250 (the BigCommerce max per page)

If the result count equals 250, more pages exist - the next step handles that.

Step 4: Loop Over Pages

Wrap the fetch in a Loop set to While with the condition {{ lastPage.length }} === 250. Increment a page variable each iteration and pass it as the page param to list-orders. Collect every page's results into a single allOrders array. Stop when a page returns fewer than 250 rows.

Step 5: Transform - Shape for MongoDB

Add a Transform node to prepare documents:

Set _id to the BigCommerce id so upserts are idempotent.
Parse date_created and date_modified from BigCommerce's RFC 2822 format into ISO 8601 (analysts will thank you).
Add syncedAt with the current timestamp so dashboards can show data freshness.
Optionally use the json connector with pick to drop fields you'll never query.

Step 6: Upsert to MongoDB

Wrap the next step in a Loop over the transformed orders. Inside the loop, add a Connector node for the mongodb connector and pick the update-documents tool:

Database: bc_mirror
Collection: orders
Filter: { "_id": "{{ order._id }}" }
Update: { "$set": {{ order }} }
Upsert: true

After the loop, route to a slack send-message step with a summary ("Synced 1,243 orders, 0 errors") so you have a heartbeat that the job ran.

Tips

Index date_modified and customer_id - the two fields analysts will almost always filter on. _id is indexed automatically.
Pull order line items separately - BigCommerce returns orders without line products. Add a second pass using raw-api-request to call /orders/{id}/products if you need them.
Backfill once - on first deploy, run the workflow once with syncStart set to your store opening date. After that, incremental runs are quick.

Common Pitfalls

Rate limits - BigCommerce caps API requests per second per store. If you upsert 1,000 orders in a tight loop, you'll hit the ceiling. Keep the upsert inside a sequential Loop so calls run one at a time, and batch larger updates into fewer documents where you can.
Order status changes - BigCommerce updates date_modified when status changes (e.g. shipped, refunded). Your mirror reflects the latest state, not a point in time. If you need history, append to a second order_events collection.
Timezone on dates - BigCommerce returns timestamps in the store's timezone, not UTC. Convert explicitly or your window filters drift across DST.

Testing

Set syncStart manually to one hour ago and run the workflow once. Open MongoDB Compass (or your tool of choice) and check a few documents: are _id and the parsed dates correct? Compare the count to the BigCommerce admin filtered to the same window. If both match, turn the schedule on.