Store settings

How do I set up webhooks to send order and session events to an API or email?

Create and manage store webhooks in Settings: choose API or E-mail, pick the session-created, order-created, or order-updated event, use {{placeholder}} URLs, and learn the 20-webhook limit, retry backoff, and the owner failure email after 5 consecutive failures.

What webhooks do

A webhook subscribes to a specific store event. When that event happens, Storeep immediately sends the event data to a URL you specify (API type) or to an email address you specify (E-mail type). Webhooks are commonly used for order tracking integrations, CRM syncs, ad platform conversions, and automated notifications.

To manage webhooks, go to Settings → Webhooks. You need the settings permission to view or change webhooks.

Webhook limits

Maximum 20 webhooks per store. Trying to add a 21st returns the error "You have reached the maximum of 20 webhooks per store".
The list shows webhooks newest first, paginated at 40 per page.

Creating a webhook

Click Add new webhook, fill in the fields below, then click Add.

Activate

Checked by default. When checked, the webhook is live the moment you save it and matching events are dispatched. Uncheck it to save the webhook in a disabled state that receives nothing. You can flip this at any time by editing the webhook.

Name

Required. Maximum 50 characters.
A descriptive label shown in the list, for example Facebook CAPI order created.

Type

API: Storeep sends an HTTP POST request carrying the event data to your URL.
E-mail: Storeep sends an email containing the event data to your address.

Event

The store event that triggers the webhook. Three events exist:

Session created: a new visitor session is created in your store.
Order created: a new order is placed.
Order updated: an existing order's status or data changes.

Important: the E-mail type only delivers Order created and Order updated. If you pick E-mail with Session created, the webhook saves but never sends anything. Use the API type if you need the session event.

Format

Only one option, Json: the payload is sent as a JSON document.

URL (API type only)

Required when the type is API. Maximum 500 characters.
The field shows an https:// prefix for you, so enter the host and path only, for example api.example.com/events/order. If you do paste a full https:// or http:// address, the prefix is stripped before saving.
Dynamic placeholders: inject any field from the event data into the URL with double-brace syntax {{field_name}}. Example: example.com/postback?cid={{fbclid}}&payout={{order_total}}. Values are URL encoded, and a placeholder whose field is missing resolves to an empty value. This lets you send conversion data straight to an ad platform without a proxy.
The address is validated after placeholders are removed, so an invalid URL returns "The url you have entered is incorrect".

Email address (E-mail type only)

Required when the type is E-mail. Must be a valid address, maximum 127 characters.

Editing a webhook

Click any row to open the editor. Every field is editable. The URL field pre-fills only when the saved type is API, and the email field pre-fills only when the saved type is E-mail. Click Save to apply. Saving with Activate unchecked disables the webhook without deleting it.

Webhooks list columns

Name: the label with its creation date.
URL / E-mail: the destination.
Type: API or E-mail.
Event: Session created, Order created, or Order updated.
Format: Json.
Status: Activated or Deactivated.

Deleting a webhook

Select one or more rows and click Delete webhooks. Deletion is permanent and stops all future deliveries for that subscription.

Delivery, retries, and failure emails

This section applies to API webhooks. E-mail webhooks are fire and forget: they are sent once with no retry and no failure tracking.

Retry behavior

Each request has a 5 second timeout. If a target returns a 5xx error, 429 (rate limited), or cannot be reached (connection error), the delivery is treated as a temporary failure and retried.
After the first delivery fails, Storeep retries with exponential backoff over up to 5 retries: about 30s, 60s, 120s, 240s, then 480s later. After the final retry the event is dropped.
A 4xx response other than 429 (for example 404 or 403) is treated as a permanent failure. Storeep does not retry it, because a wrong or rejecting endpoint will not fix itself.
When you have several webhooks on the same event, a retry only re-sends to the ones that failed. Endpoints that already returned success are skipped, so you do not get duplicate deliveries.

Failure notification email

Storeep counts consecutive failed deliveries per webhook. After 5 consecutive failures, the store owner gets one email titled "Action needed: your Storeep webhook is failing", in the owner's language, listing the webhook name, destination, event, and the last HTTP status code.
You get exactly one email per failing streak. No further emails are sent until that webhook recovers.
As soon as a delivery succeeds again, the failure counter resets to zero and the notification re-arms, so a future broken streak can email you again.

Tips and pitfalls

You can create multiple webhooks for the same event, for example send Order created to both a CRM and an ad platform as two separate entries.
If your endpoint needs authentication, put a token in the URL query string, either hardcoded or via a {{placeholder}} from the event data, or front it with a proxy that adds the auth before forwarding.
Session created fires for every unique visitor session and can be high volume on busy stores. Only subscribe to it if your endpoint can handle the throughput, and remember it only works with the API type.