Skip to main content
Pulses are webhook notifications that allow you to receive real-time HTTP POST requests when specific events occur in your Chariow store. Instead of constantly polling the API, Pulses push event data to your configured endpoint URL as soon as something happens, enabling you to build responsive integrations and automations.

How Pulses Work

1

Event Occurs

An event happens in your store (e.g., a sale is completed).
2

Pulse Triggered

Chariow sends a signed HTTP POST request to your configured endpoint.
3

Verify the Signature

Your server checks the x-chariow-signature header before trusting the payload.
4

Process the Event

Your server deduplicates on x-pulse-delivery-id and processes the payload.
5

Acknowledge Receipt

Your server returns a 2xx status code to confirm receipt.
Your endpoint URL is public, so anyone who discovers it can post to it. Always verify the signature before acting on a payload — see Pulse Security.

Request Headers

Every delivery carries these headers:
Full signing contract, verification snippets and troubleshooting: Pulse Security.

Setting Up Pulses

You can configure Pulses in several ways:

Via Store Dashboard

  1. Go to AutomationPulses
  2. Click Add Pulse
  3. Enter your webhook endpoint URL (must be HTTPS)
  4. Select the events you want to receive
  5. Optionally select specific products (leave empty for all products)
  6. Save your Pulse
Your Pulse endpoint must be accessible via HTTPS. HTTP endpoints are not supported for security reasons.

Pulse Events

Pulses support the following events. When an event fires, the webhook payload contains an event field with the event value.

Sale Events

License Events

Affiliate Events

You can configure multiple events for a single Pulse URL. When any of the selected events occur, Chariow will send a webhook notification to your endpoint with the corresponding event value.

Pulse Payload

When a configured event occurs, Chariow sends an HTTP POST request to your webhook URL with event data in the request body. The exact payload structure depends on the event type.
Pulse payloads contain comprehensive event data, including details about the entity (sale, license, etc.), customer information, product details, and store context. The payload structure varies by event type to provide relevant information for each event.

Successful Sale Example

When a successful sale occurs, Chariow sends a webhook with the successful.sale event:

License Activated Example

When a license is activated, Chariow sends a webhook with the license.activated event:

License Nearing Expiry Example

Chariow scans licenses daily and sends the license.nearing_expiry event once per license, as soon as it enters the seven-day window before its expires_at date. Use it to prompt a renewal before the customer loses access.
days_until_expiry is only present on this event. It is rounded up, so a license lapsing in a few hours reports 1. A license is announced once and only once, even if the scan runs again before it expires.

Affiliate Joined Example

When a new affiliate joins your store, Chariow sends a webhook with the affiliate.joined event:
The exact payload structure may include additional fields depending on the event type and context. Always check the actual payload received at your endpoint for the complete data structure.

Handling Pulses

Basic Example (Node.js/Express)

PHP Example

Retry Policy

If your endpoint doesn’t respond with a 2xx status code, Chariow retries the delivery. A delivery gets 5 attempts in total, spaced with an exponential backoff: Each attempt times out after 30 seconds. The signature is computed once at dispatch and reused unchanged by every retry, so a retry landing hours later still verifies.
After the 5th failed attempt on a single delivery, the Pulse is disabled automatically and the store owner, admins and marketing team members receive an email. You must re-enable it from the dashboard before it fires again — and before you can replay its deliveries.
Ensure your Pulse endpoint responds quickly (within 30 seconds). Long-running processes should be handled asynchronously.

Delivery History and Replay

Every attempt is recorded, so you can see whether Chariow ever called your endpoint and what it answered. Open Automations → Pulses → select your Pulse → Deliveries tab. The table lists each delivery with:
pending means queued or mid-retry, not failed. A delivery only becomes failed once all 5 attempts are exhausted.
Clicking a row opens the sent payload, the response and the delivery id. Replay re-sends a stored payload to the same endpoint without reprocessing the original sale or licence event — useful when your endpoint was down, or while you are debugging signature verification.
A replay is a new delivery with a new x-pulse-delivery-id, so it passes your idempotency check and will be processed again. That is intentional.

Best Practices

Return a 200 response immediately, then process the Pulse asynchronously to avoid timeouts:
Due to retry logic, the same delivery may reach you more than once. Deduplicate on the x-pulse-delivery-id header, which is stable across every attempt of a delivery:
Do not deduplicate on the entity id inside the payload: one sale legitimately produces one delivery per subscribed Pulse.
Never act on a payload before checking x-chariow-signature. See Pulse Security for the full contract and ready-to-use snippets.
Always use HTTPS for your Pulse endpoint to ensure data is encrypted in transit. Chariow will reject HTTP endpoints for security reasons.
Check the Deliveries tab of your Pulse regularly. It shows the status code and response body of every attempt, so you can diagnose failures without adding logging on your side.
For high-volume stores, consider creating separate Pulses for different products to make processing more efficient and organised.

Testing Pulses

Use the Pulse testing feature in your dashboard:
  1. Go to AutomationsPulses
  2. Click on your Pulse
  3. Click Send test pulse
  4. Check your endpoint received the test payload
A test event is signed exactly like a real one, but it carries no x-pulse-delivery-id header (no delivery record is created for it) and its payload contains an extra note field. To validate your integration against a real payload, replay a delivery from the Deliveries tab instead.
For local development, use a service like ngrok to expose your local server to the internet.

Managing Pulses via API

You can programmatically manage your Pulses using the Chariow Public API:

List All Pulses

Example List Response

Get a Specific Pulse

The response for a single pulse uses the same structure as each item in the list response.

Filter Pulses

You can filter pulses by URL or event type using the search parameter:
For complete API documentation, see the List Pulses and Get Pulse endpoints.

Pulse Security

Verify signatures and deduplicate retries

API Reference - List Pulses

View detailed API documentation

API Reference - Get Pulse

Get a specific pulse via API

Sales Guide

Learn about sale events

Licenses Guide

Learn about license events

Affiliates Guide

Learn about affiliate events