Set up an endpoint

Prepare a receiver at a public HTTPS URL and a secret store. For a local application, first follow local development.

Create the endpoint

Open webhook settings

Open Settings → Webhooks in the dashboard for the intended merchant and environment. Choose Add Endpoint. The wizard has Endpoint, Events, Security, and Confirm steps.

Use the final HTTPS route, such as https://your-app.example/webhooks/revkeen. It must accept POST requests without a browser sign-in screen. Keep webhook signature verification enabled; it is separate from browser session authentication.

Select events

Choose the events needed for the workflow. Start with invoice.paid for invoice fulfilment or payment.succeeded for payment reconciliation. Review the catalogue.

Store the signing secret

Complete Security and Confirm. Save the returned signing secret as REVKEEN_WEBHOOK_SECRET in your receiver's secret store. This endpoint secret is separate from your RevKeen API key (rk_live_ or rk_sandbox_). Keep both server-side.

Verify a delivery

Use the endpoint's test action, then inspect Deliveries and your receiver logs. A test proves delivery and signature handling; it does not prove a real payment lifecycle. Verify the intended staging workflow separately with the appropriate provider configuration.

API setup

Use the Webhook Endpoints reference for request fields and response schemas. Store the returned signing secret before leaving setup.

Each enabled_events value is one of:

*, for every event;
an event name from the catalogue, such as invoice.paid;
a prefix wildcard, such as invoice.*, which matches every event under that prefix.

Any other value, including a misspelt name or a leading wildcard such as *.paid, is rejected with 400 and the error code invalid_event_type. The error lists the rejected values in invalid_values, and nothing is created or changed. Repeated values are stored once. When more than one value matches an event, such as * and invoice.paid, the endpoint still receives that event once.

Rotate without assuming an overlap window

The current rotation operation replaces the stored secret; it does not advertise an old/new secret grace period. For a coordinated transition:

Create a replacement endpoint and store its separate secret.
Configure your receiver to verify the appropriate endpoint secret and deduplicate shared events.
Verify delivery through the replacement.
Disable the old endpoint, account for in-flight deliveries, then retire its secret.

Two enabled endpoints can deliver the same event. For in-place rotation, coordinate the receiver update and inspect/retry any failed deliveries during the transition.

Redeliver an event to one endpoint

To send an event to one endpoint again, for example after fixing your receiver, call POST /v2/webhook-endpoints/{id}/redeliver with the event's event_id. You can find it on any of the event's deliveries (GET /v2/webhook-deliveries). RevKeen sends the original payload to that endpoint only, as a new delivery with its own attempts.

The endpoint must be enabled and subscribed to the event's type. Otherwise you get 409 with endpoint_disabled or endpoint_not_subscribed, and nothing is sent.
If a redelivery of the same event to the same endpoint is still pending, the call returns that delivery instead of creating another.
Send an Idempotency-Key header so that retrying the request is safe.

POST /v2/events/{id}/resend is deprecated in favour of this route. It keeps working, and its responses carry a Deprecation header.

Disable or delete an endpoint

Disabling an endpoint (enabled: false on update) stops new deliveries and keeps its delivery history, so you can still list and inspect those deliveries.

Deleting an endpoint is permanent. It removes the endpoint, its event subscriptions and its delivery history: those deliveries no longer appear in the delivery list and cannot be retried. If you may need the history, disable the endpoint instead, or read the deliveries you need before you delete it.

Continue with receiving events.

Last updated 10 Oct 2026 by David Lindblad · Owner: david · Reviewed 30 Sep 2026 · Next review 30 Oct 2026