What it logs

Four streams,
one searchable timeline.

Your store already emits all of this. Auditor catches it, gives every source the same shape, and keeps the value before and after each change so a row answers the question on its own.

18 event types out of the box Before and after values Read scopes only · never writes

The unit of the log

What a single row holds

Every source — webhook, login, API call, system error — is normalised into this same nine-field record.

audit_record · one row, expanded product.updated
  • timestamp2026-08-26 14:22:07 IST
  • eventproduct.updated
  • userpriya@yourstore.com · staff
  • sourcewebhook
  • resourceproduct 4482 · SKU HQ-441
  • ip address203.0.113.44
  • storeabc123def · channel 1
  • afterprice 1,149.00 · −11.5%
  • User, not just "the system" A staff email, a storefront session, an app's token label or an API key — whichever one made the change. Rows without a known actor say so rather than guessing.
  • Detailed change information Auditor shows the updated value and the details of what changed, making it easy to understand the latest state of the store.
  • Resource IDs you can act on Product, order and customer IDs are kept raw, so a row links straight back to the record in your BigCommerce admin.
  • One shape for every source Because a login and a price change share a structure, one filter and one search box cover the whole history — no switching tools mid-investigation.

The sources

Where the rows come from

Four streams land in the same timeline. Filter to one when you know where to look, leave them merged when you don't.

webhooks

Catalog and order activity

Subscribed automatically on install. Every create, update and delete on the records that carry your money.

  • product.creatednew SKU, with its opening values
  • product.updatedprice, stock, title, status
  • product.deletedlast known state retained
  • order.createdorder number and total
  • order.updatedstatus and fulfilment moves
  • order.refundedamount and who issued it
  • customer.createdsignup source
  • customer.updatedemail and address edits
people

Staff logins and sessions

Who got in, who tried, and from where. Repeated failures rise to the top instead of hiding in the noise.

  • auth.loginsession opened, with IP
  • auth.login.failedcounted per IP and per account
  • auth.logoutsession closed
  • staff.permission.changedrole granted or revoked
api

API and app traffic

Calls from your own integrations and from other installed apps, with the token label attached — useful when two apps disagree about inventory.

  • api.token.usedwhich key, which endpoint
  • inventory.updatedold and new stock levels
  • settings.changedpayment, shipping, tax
  • app.installedand uninstalled
system

System and error logs

Kept next to the business events, so troubleshooting is one search instead of three tabs.

  • webhook.faileddelivery error and reason
  • webhook.retriedattempt number
  • validation.errorpayload that didn't fit
  • export.generatedwho exported what, and when

Boundaries

What stays out of the log

An audit trail is only useful if it isn't also a liability. These never enter it.

Never recorded

  • Card and payment details. Auditor never sees them; BigCommerce doesn't expose them to apps.
  • Customer passwords or password hashes, in any form.
  • Storefront browsing. No visitor tracking, no cookies dropped on your storefront.
  • Anything written back to your store. The app holds read scopes, so it can't change a record even by accident.

How rows are handled

  • History starts at install. Auditor can't recover changes made before it was added.
  • Retention is 90 days per store during beta, then per your plan.
  • Review activity details. Open a recorded activity to view the available event information and understand what happened in your BigCommerce store.
  • Deletion on request. Written to the privacy address, confirmed before anything is removed.

See it against your own store's activity.

Auditor is free through the beta, and starts recording the moment it's installed.