Structural Reconstruction Engine
The Structural Reconstruction Engine explains how a captured request was evaluated. It reconstructs the provider signing contract from the raw request and records each validation stage instead of returning only pass or fail.
The engine runs during webhook processing and its report is stored with the validation result. A failure in the intelligence layer does not prevent the webhook from being captured.
Reconstruction pipeline
| Stage | What is recorded |
|---|---|
| 1. Raw body capture | Whether the byte-preserving raw body was available, its length, and whether a fallback was used. |
| 2. Provider detection | Provider candidates, confidence level, confidence score, and matching signals from headers and payload structure. |
| 3. Signature extraction | The header used and the number or format of signatures found. |
| 4. Key preparation | Key format and processed length; the secret value itself is not included in the report. |
| 5. Signed payload construction | The configured template and resulting signed-payload length. |
| 6. HMAC computation | Algorithm, encoding, and output length. |
| 7. Signature comparison | Whether the received and computed signatures matched. |
| 8. Timestamp validation | Timestamp age and tolerance when the provider contract uses a time window. |
Provider coverage
Structural reconstruction recognizes common signing patterns for Stripe, GitHub, Shopify, Razorpay, Svix, and generic HMAC requests.
Endpoint signature validation is configured separately when you create the endpoint. Choose a validator shown in the endpoint form that matches the sender contract.
Root-cause matching
- Known provider and generic patterns are checked first and return deterministic diagnoses and fixes when their structural fingerprints match.
- Additional known failure patterns can provide a diagnosis when their structural evidence matches.
- Unmatched failures retain a structural fingerprint for later analysis; raw secrets and payload content are excluded from that fingerprint.
Reading a divergence
The divergence step identifies the first stage that could not be completed or did not match. Use it with the captured headers, raw body, provider delivery record, and application logs; it is diagnostic evidence, not proof that the provider or application is solely at fault.