Setting up webhooks

Use Webhooks to notify another system when something happens in your Nevuto store. For example, send an Order paid event to your order-processing service or notify an inventory service when stock changes. Nevuto sends an HTTP POST request to the endpoint you configure.

These are outgoing store-event webhooks. They are configured separately from incoming payment-provider callbacks and the Send webhook action inside an automation.

Before you start

• Sign in as the store owner or with a staff account allowed to manage store settings.
• Have a receiver endpoint you control, or one supplied by the service you are connecting. It must be publicly reachable over HTTPS.
• Have a developer or service administrator confirm that the receiver accepts the event, JSON or XML format, and webhook API version you will select.
• Prepare the receiver to verify signatures, handle duplicate requests, and respond promptly.

The endpoint must return a 2xx status within 10 seconds. Private-network addresses and URLs containing embedded login credentials are rejected. Redirects are not followed, so enter the final receiving URL rather than a URL that redirects elsewhere.

Open Webhooks

In Nevuto Admin, open Settings > Notifications > Webhooks. The page contains your webhook subscriptions, the store's Signing secret, and Recent deliveries.

The demo store before any subscription was created. The real signing secret remains masked. Select an image to enlarge it.

Choose the event you need

1. Click Create webhook.
2. Open Event and choose the event that should notify your receiver.

Events are grouped by resources such as orders, customers, products, inventory, checkouts, returns, and other store activity. A subscription selects one event. Create separate subscriptions if your receiver needs several events; they can use the same endpoint when your receiver supports that.

The actual event picker. Order created and Order paid are different events; choose the one that matches your workflow. An order being created is not, by itself, confirmation that payment was received.

Configure and save a subscription

Complete the Create webhook dialog:

1. In Event, select the intended event, such as Orders · Order paid.
2. In Format, choose JSON or XML to match your receiver. JSON is selected initially.
3. In Endpoint URL, enter the final public HTTPS receiving address.
4. In Webhook API version, choose a version your receiver supports. The current option shown in this guide is 2026-10 (Latest). The selected version is stored with the subscription and included in its deliveries.
5. Click Save. Resolve any validation error and confirm the webhook appears as Active in the list.

Prepared, unsaved example using https://example.com/webhooks/nevuto. Replace it with your own receiver; this example address was not saved or contacted. Saving creates an active subscription, so have your receiver ready first.

Saving validates the configuration and endpoint address; it does not prove your receiver can process a delivery. Closing the dialog with Cancel abandons its unsaved settings.

Verify signatures at your receiver

In Signing secret, use Copy secret to transfer the store's secret directly to your receiver's private configuration. Keep it out of public pages, screenshots, URLs, and logs. It is separate from an account password or an app API credential.

Every request from these store subscriptions includes X-Nevuto-Hmac-Sha256. Calculate HMAC-SHA256 of the raw request body using the store signing secret, then Base64-encode the binary digest.

Compare the result with the header using a constant-time comparison before processing the request. Use the exact raw body bytes: parsing and re-encoding JSON, changing whitespace, or reformatting XML before verification changes the signature.

The request also includes useful headers:

• X-Nevuto-Topic: the event name, such as orders/paid.
• X-Nevuto-Webhook-Id: the event identifier, retained across retries and a manual resend.
• X-Nevuto-Shop-Id and X-Nevuto-Shop-Domain: the originating store.
• X-Nevuto-Api-Version: the selected webhook payload version.
• X-Nevuto-Triggered-At: the delivery record's timestamp.

JSON deliveries use application/json; XML deliveries use application/xml. The event payload includes an ID, topic, API version, event time, store information, and an event-specific data object. Parse the format you selected rather than assuming every request is JSON.

Have the receiver remember processed event IDs for each store. A repeated request should receive a successful acknowledgement without performing the same business action twice. Persist accepted work before acknowledging it, and move slow processing to your own background worker so the HTTP response stays within the timeout.

Send a test and verify the result

After saving your own subscription:

1. Open its three-dot actions menu and choose Send test.
2. Check the result notification and find the request in Recent deliveries, using Refresh if needed.
3. Confirm that your receiver verifies the signature and understands the selected format and version.
4. Open the delivery to inspect its request, response, status, and timing.
5. When ready, perform the relevant real store action and verify that its actual event also reaches the intended system.

Send test makes a real HTTP request to your configured endpoint, using a sample payload for the selected event. It does not create a real order or customer. Test data includes a test flag inside the payload's data object; your receiver should avoid treating the sample as a real business transaction.

Test sends make one immediate attempt. A successful test confirms receipt of that sample; it does not establish that all future business events will be handled correctly. The screenshots in this guide show configuration screens, not a completed delivery test.

Inspect Recent deliveries

Recent deliveries includes requests from saved webhooks, automation webhook actions, and tests. Use its search and filters to narrow results by Webhook, Status, or Source. The source filter distinguishes Webhook, Automation, and Test.

The real delivery log in the demo store, with no requests sent. No delivery rows, response codes, or success states were fabricated for this guide.

The statuses mean:

• Pending: queued and not yet completed.
• Retrying: an attempt failed and another attempt is still due.
• Delivered: the endpoint returned a 2xx response.
• Failed: the delivery is terminal, including exhausted attempts or an invalid destination.

Open a row for Delivery details. It shows the event, endpoint, response code, duration, attempt count, format/version, Webhook ID, and request body. An available response body or error helps explain what happened. Custom headers lists custom header names when present; it does not display the secret values or serve as a full HTTP-header capture.

Normal queued delivery failures can receive up to five attempts. Invalid or unsafe endpoint addresses can fail without further attempts. Test sends and manual resends use a single immediate attempt. Delivery logs are cleaned up after 30 days; use your receiver's own records if you need a longer history.

Resend, edit, pause, or delete

To retry a past request manually, open Delivery details and click Resend. This creates another delivery record from the original request, retaining its event ID, payload, endpoint, format, and API version. Editing a subscription's URL does not redirect a resend of an older delivery to the new URL. Check the recorded destination before resending.

Use the subscription's three-dot menu to manage future events:

• Edit webhook opens its configuration. Review the event, URL, format, and API version, then Save.
• Pause stops the subscription being selected for new events. Resume enables it again. Already queued requests may still be delivered, and events missed while paused are not automatically replayed on resume.
• Delete webhook removes the subscription after confirmation. Past delivery records remain until normal cleanup.

The current limit is 50 saved webhooks per store. Search or clear list filters if a subscription seems to be missing before creating another one.

Rotate the signing secret carefully

Rotate secret changes the store-wide signing secret immediately after confirmation. New outgoing attempts then use the new secret, including attempts for existing store delivery records. Updating a single webhook's URL or format does not rotate this secret.

Coordinate the change with whoever operates every receiver using that store secret. Ensure each receiver can be updated before rotating, transfer the new secret privately, and verify new requests after the change. Rotation is not required to create another subscription or send a test.

Troubleshooting