Who this is for
A founder, operations lead or technical contact who needs one outside service to push events into their own system and cannot rely on an unauthenticated URL.
A tool you use can send webhooks, but you have no receiver yet, or your current endpoint accepts any request, answers too slowly, or acts twice when a delivery is repeated.
The result
Against synthetic signed deliveries, the receiver accepts a correctly signed event and acts on it once in effect; rejects an altered body, a wrong secret and a missing signature without storing or acting on them; answers within the sender's documented time limit; treats a repeated delivery as already handled, including a captured copy whose unsigned identifier header has been changed; and loses nothing and doubles nothing when it is stopped between storing a delivery and acting on it.
What is included
- One sender, one event type and one action in your system, such as creating a task or updating one record
- Signature verification over the exact received request body, using a constant-time comparison and a secret you hold in your own configuration; where the sender signs a timestamp, a delivery older than the sender's documented tolerance is rejected
- A fast acknowledgement after the verified delivery is stored in one durable step, with the action run afterwards from that stored record
- A repeat key taken from the signed bytes: an event identifier inside the body where the sender provides one, otherwise a hash of the raw body. An identifier that appears only in an unsigned header is not used as the key on its own
- Handled keys kept for a retention period agreed in writing, and automated tests using synthetic deliveries, including a stop between storing a delivery and acting on it
You receive
- The receiver's source code in a repository you control, with a short readme and a configuration list that names no secret values
- Automated tests covering valid, altered, wrong-secret, missing-signature, repeated, simultaneous and header-changed replayed deliveries, a stale timestamp where the sender signs one, and a stop between storing and acting
- A runbook: how to rotate the secret, how to replay a missed delivery, and what each log line means
- A written note of the repeat key, the retention period and what the receiver does not do, such as ordering guarantees across event types
What is not included
- Deploying to production, holding your secrets or changing your DNS, which stay with your team
- More than one sender, event type or action
- Repairing an existing endpoint whose only fault is that genuine deliveries fail the signature check: that is a separate, smaller fixed-price repair for one provider and one endpoint
- Building the sender's side, or fixing the sender's own delivery problems
- A guarantee that no event is ever lost: a reconciliation job against the sender's delivery log is a separate scope
- An action that is one-way and cannot be made safe to repeat for the same event, which forces a choice between a possible repeat and a possible loss after a crash
- Security assessment, penetration testing or compliance certification
What we need from you first
- The sender's name and a link to its public webhook and signature documentation
- The event type and the one action it should cause, in a sentence
- Where the endpoint would run, and whether a durable store for received deliveries exists
- Whether you have a receiver today and what it does wrong: no verification, slow answers, repeated actions, or only rejecting genuine events
- Do not send the signing secret, API keys, customer data or source code in the first enquiry
Never send passwords, keys, customer records or confidential code in the first enquiry. Secure handover is agreed after scoping.
How we check it is done
- A synthetic delivery signed with the test secret is accepted, stored, acknowledged and causes the agreed action once in effect.
- A delivery with a body changed by one character, a delivery signed with a different secret, and a delivery with no signature header are each rejected, nothing is stored for them, and no action is taken.
- Sending the same delivery twice, and twice at the same moment, causes the action once in effect and returns a success response for the repeat; a copy of the same body with a different unsigned identifier header is also treated as a repeat.
- With the process stopped after a verified delivery is stored but before the action runs, and again after the action but before the delivery is marked done, a restart leaves exactly one effect for that delivery.
- Where the sender signs a timestamp, a delivery with a valid signature and a timestamp older than the sender's documented tolerance is rejected; the note states the retention period and, where no timestamp is signed, that a request older than it can act again.
- With the downstream work artificially slowed beyond the sender's documented time limit, the receiver still acknowledges within that limit and completes the work afterwards.
You run the automated tests and review the evidence, then sign off before payment. Your team deploys the receiver and checks one live delivery under your own keys.
When we would stop or decline
- The sender offers no signature, or an undocumented one, so there is nothing safe to verify
- The signed bytes hold no event identifier and two different genuine events can be byte-for-byte identical, so a replay cannot be told from a new event; we quote a different scope
- The action is one-way and cannot be made safe to repeat or written in one transaction with the stored delivery, so a crash forces a choice between a possible repeat and a possible loss
- The action would move money, delete data or message customers, and no reviewer on your side will approve it
- The only test route is production events carrying real customer data
Questions
Which senders does this cover?
Any sender that publicly documents an HMAC signature over the request body. We confirm the scheme from its documentation before quoting, and name the sender and event in the agreement.
What stops someone replaying a request they captured?
The receiver remembers each delivery by a key taken from the signed bytes, so changing an unsigned header does not make a copy look new. Where the sender signs a timestamp, old copies are also rejected. Where it does not, a copy older than the agreed retention period can act again, and the handover note says so.
Does this make sure no event is ever lost?
No. It makes sure each delivery that arrives is checked, stored and acted on once in effect, even if the process stops part-way. Recovering events missed during an outage needs the sender's delivery log and is a separate scope.
My endpoint exists but rejects genuine events. Is this the job?
Usually not. That is a smaller repair of one existing endpoint. This job builds a receiver with a durable record and a repeat key.
Will you hold our signing secret?
No. You generate it and keep it in your configuration. We build and test with a separate test secret.
Price and terms
From £495 · untested offer price. After the agreed checks pass and you sign off. No advance payment.
This is a new service with no published client results. The price is a starting point we have not yet tested with buyers. Nothing is ordered or charged by the enquiry. The full specification is on the Synthetic Industry catalogue.