Skip to main content
Droplinked receives webhooks. This page is the contract for configuring a provider’s dashboard to point at us, and for understanding what we do with the event.
Every path below is mounted on https://apiv3.droplinked.com. There is no /webhook/stripe route — a POST to it returns 404, so a Stripe endpoint configured there silently fails every event. Earlier revisions of these docs named that path; the real Stripe mounts are listed below.

​
Payment-provider routes

PayPal does not post directly to the Core API. PayPal events are received and signature-verified by Integration Services (paypal-transmission-sig + the configured webhook id), which then forwards a normalised event to POST /payment/webhook/generic.

​
Fulfillment routes

​
The raw-body rule

Signature verification for Stripe and MamoPay runs over the exact bytes the provider sent. If a proxy, body parser, or middleware re-serialises the JSON before it reaches the handler, verification fails even though the payload is semantically identical. If you are terminating or forwarding these events in your own infrastructure before they reach Droplinked, forward the body unmodified, and forward the signature header unmodified with it.

​
What a response code means to the sender

That 400 / 503 split is deliberate: an internal fault must never be reported as a permanent rejection, because that drops a genuine money event on the floor.

​
Replay and duplicate delivery

Providers retry. Assume at-least-once delivery and design for duplicates. Two mechanisms exist on our side, and it is worth knowing which one is load-bearing:
  1. Event-id dedupe — a per-provider cache keyed on the provider’s event id, with a 24-hour window. It absorbs a provider retry that lands on the same application instance. It is in-process: it does not span instances and does not survive a restart, so do not treat it as a guarantee.
  2. Forward-only order state — the durable one. Order state machines do not rewind. A stale AUTHORIZED event arriving after CAPTURED is dropped rather than applied, and re-applying a terminal transition is a no-op.
The practical consequence for a partner: re-delivering an event is safe, and you do not need to coordinate with us before replaying a backlog.

​
Outbound webhooks

Droplinked can also dispatch events to a merchant-registered endpoint, with a per-subscription signing secret that can be rotated, and a delivery log keyed <subscriptionId>:<eventId> so a redelivery is not double-counted. This surface is not self-serve today — ask your Droplinked counterpart if you need it.