Signed payloads only
Every webhook is checked against its signature before it's parsed. Unsigned or replayed requests are rejected and recorded as rejected.
How it works
No theme edits, no scripts on your storefront, no manual endpoint setup. Install it, approve read scopes, and events start arriving — typically searchable within half a second.
One event, end to end
Someone edits a price in your admin. Here's the distance between that click and a row on your dashboard.
A change is made in your BigCommerce store, such as creating, updating, or deleting a record.
The event is sent to the webhook endpoint registered for your connected store.
The webhook event details are received and saved as an activity log for the store.
Recorded activities are displayed in the dashboard so you can review what happened.
When additional change information is required, the app can retrieve details from the BigCommerce Staff Action Log.
Webhook-based activity capture. Activity records are received from BigCommerce through registered webhooks and saved for viewing in the dashboard.
The path of one event
See how a BigCommerce activity moves from app installation to your dashboard.
Install the app from BigCommerce and approve the requested access scopes to connect your store.
After token verification, the app completes the connection and redirects you to the dashboard.
When an activity occurs in your store, the registered webhook sends the event details to the app.
The received webhook details are stored as an activity log associated with your connected BigCommerce store.
Open the dashboard to view the recorded activity and its available event information.
When detailed staff information is required, the app can retrieve the relevant activity from the BigCommerce Staff Action Log.
Under the hood
An audit log you can't trust is worse than none, because you'd stop double-checking.
Every webhook is checked against its signature before it's parsed. Unsigned or replayed requests are rejected and recorded as rejected.
Incoming events go to a queue and are processed by background workers, so a bulk import doesn't cost you records.
Failed processing is retried on a backoff, and both the failure and the retry appear in your system stream.
Webhooks can arrive more than once. Events are de-duplicated on delivery so your timeline doesn't double-count a change.
Rows are written once and never edited in place. Nobody — including us — rewrites what your store recorded.
Every record carries its store ID and is queried per store. Your log is never mixed with anyone else's.
Once it's recording
Review your store activity and get notified when new staff activity is detected.
Review the activities captured from BigCommerce webhooks and see the available event information directly from the dashboard.
Open an activity to review its details. When additional information is required, the app can retrieve details from the BigCommerce Staff Action Log.
The app compares the latest scraped Staff Action Log activity with the last recorded scrape date to identify newer staff activity.
When staff activity is found after the date configured in your preferences, the new activity is processed and an alert is shown on the Staff Log page and sent by email.
The app uses the required BigCommerce access scopes to read store information and receive activity events. It does not use write access to create, edit or delete store data.
Auditor starts recording the moment it's installed. It can't recover what happened before that.