Bc Webhooks

BigCommerce Webhooks

Before writing code

Fetch live docs:

1. Fetch https://docs.bigcommerce.com/developer/docs/integrations/webhooks/overview for webhooks guide
2. Web-search site:developer.bigcommerce.com webhooks events reference for event topics
3. Web-search bigcommerce webhook payload format for payload structure

How Webhooks Work

Event-Driven Notifications

When events occur in a BigCommerce store, HTTP POST requests are sent to your endpoint:

1. Register a webhook via the REST API (or admin)
2. BigCommerce fires the webhook when the event occurs
3. Your endpoint receives a POST with the event payload
4. Respond with 200 OK to acknowledge receipt
5. Use the event data to trigger your business logic

Webhook Lifecycle

• Created via POST /v3/hooks
• Active immediately after creation
• BigCommerce retries on failure (non-2xx response)
• Deactivated after repeated failures
• Manageable via REST API (list, update, delete)

Managing Webhooks

Create

POST /v3/hooks
{
  "scope": "store/order/created",
  "destination": "https://your-app.com/webhooks/orders",
  "is_active": true,
  "headers": {
    "X-Custom-Header": "my-verification-value"
  }
}

List

GET /v3/hooks — returns all registered webhooks.

Update

PUT /v3/hooks/{id} — update destination, scope, or active status.

Delete

DELETE /v3/hooks/{id} — remove a webhook.

Event Topics

Order Events

Product Events

Customer Events

Cart Events

Other Events

Payload Format

Standard Payload

{
  "scope": "store/order/created",
  "store_id": "1234567",
  "data": {
    "type": "order",
    "id": 5678
  },
  "hash": "abc123def456...",
  "created_at": 1706140800,
  "producer": "stores/{store_hash}"
}

Key Fields

• scope — the event topic
• store_id — the store's numeric ID
• data.type — resource type
• data.id — resource ID (use to fetch full details via API)
• hash — unique event hash for deduplication
• created_at — Unix timestamp

Important: Lightweight Payloads

Webhook payloads contain only the resource ID, not the full resource. You must make a follow-up REST API call to fetch the complete data:

// Webhook says: order 5678 was created
// Fetch full order: GET /v2/orders/5678

Retry Logic

BigCommerce Retry Behavior

• Retries on non-2xx responses
• Exponential backoff between retries
• Deactivates webhook after consecutive failures (typically ~30 days of failures)
• is_active set to false when deactivated

Your Handler Requirements

• Respond with 200 OK quickly (within a few seconds)
• Process the event asynchronously if it requires heavy computation
• Handle duplicate deliveries (use hash for idempotency)
• Handle out-of-order delivery (events may arrive out of sequence)

Verification

Custom Headers

Include custom headers in webhook registration for basic verification:

{
  "headers": {
    "X-Webhook-Secret": "my-secret-value"
  }
}

Verify the header value in your handler to confirm the request is from BigCommerce.

Best Practices

• Always respond with 200 OK quickly — process asynchronously
• Use the hash field for idempotency (deduplication)
• Implement custom header verification for security
• Fetch full resource data via API after receiving the webhook
• Handle webhook deactivation — monitor and re-register if needed
• Subscribe only to events you need — don't subscribe to everything
• Use a message queue (SQS, Redis, RabbitMQ) for reliable async processing
• Log all received webhooks for debugging

Fetch the BigCommerce webhooks documentation for the complete list of event topics, payload formats, and retry behavior before implementing.