AutoCore Webhook Architecture and Verification
A provider-neutral view of inbound callback transport and adapter verification.
A webhook route is deliberately narrow: accept the provider callback, authenticate it with the provider's mechanism, normalize the event, deduplicate it, reconcile it with local state, and return a safe response.
Release candidate source
This article reflects the audited AutoCore source revision 7a504f6e430c16d4fcb03ebdea3cc3fb7816df60 and immutable release-candidate tag v1.0.0-rc.1 at 9edfb109f44cc80385784c694b96392cfc04e70f. Configuration and external provider behavior remain deployment-dependent.
Source boundary
| Control | Source-verified behavior |
|---|---|
| Transport | Provider callback routes are public by network necessity but guarded by feature flags and signature verification. |
| Normalization | The adapter maps provider status, event identity, amount, currency, and references into local state. |
| Idempotency | Provider plus event ID is unique; already processed or terminal events are ignored safely. |
| Response | The endpoint does not expose credentials, internal stack traces, or local database details. |
Operational controls
Use the smallest verified control for the task. Keep provider, host, legal, and operator responsibilities separate from application behavior. When a control is not implemented or not verified, leave it disabled or mark it as a limitation.
Verification
Verify the route, relevant API or configuration state, negative path, audit/evidence result, and public effect before closing the task. Record unknown or configuration-dependent behavior as a limitation.