Use webhook-custom when the downstream system needs a specific HTTP method, headers, or payload structure that the basic webhook handler cannot express. Use webhook for straightforward delivery, log when the main need is auditability, and lambda only when you need custom runtime logic inside the gateway. The right choice is driven by integration shape, not by convenience.
Choosing the Delivery Pattern by Integration Shape
Webhook-custom is the right fit when the event receiver is not happy with a generic push and needs the sender to shape the request more precisely. That typically means a required HTTP method, a fixed header set, a particular body layout, or a signing and authentication pattern that the basic webhook abstraction does not expose. In practice, the decision is about contract fit, not about which option sounds most powerful.
A standard webhook is still the best default when the event can be delivered as a straightforward outbound HTTP call with minimal transformation. If the receiver is expecting a simple notification and you do not need to vary the request beyond the built-in handler, customisation usually adds needless complexity. The most reliable choice is the one that preserves the downstream contract without introducing extra moving parts.
Log is different because it is oriented around observability rather than active delivery. It is the right choice when the goal is to record that an event happened, preserve an audit trail, or support later inspection by humans or systems. If the downstream system must act immediately on the event, logging alone is the wrong pattern because it depends on something else reading and interpreting the record later.
Where Lambda Fits in the Decision
Lambda belongs in the small subset of cases where the gateway must do more than format a request. Use it when the automation needs custom runtime logic, conditional branching, data enrichment, request choreography, or non-trivial error handling before the event is sent onward. That makes lambda the most flexible option, but also the one with the greatest maintenance and testing burden.
The key distinction is that webhook-custom changes the outbound shape, while lambda changes the processing behaviour. If the only problem is that the target expects a different method or header set, lambda is usually excessive. If the integration requires calculating values, calling another service, or deciding between multiple downstream actions, lambda is justified because the request can no longer be expressed as a simple static delivery.
Teams should also think about failure mode. Webhook and webhook-custom are usually easier to reason about because the integration surface stays narrow. Lambda can absorb complexity that would otherwise sit in the receiver, but that same flexibility can hide logic drift, make retries harder to reason about, and create debugging gaps if the transformation layer becomes the real place where decisions are made.
Practical Selection Rules for Event-Driven Automation
A useful rule of thumb is to start with the smallest mechanism that satisfies the target contract. Choose webhook when the event can be delivered as-is, webhook-custom when the HTTP request must be shaped to match a specific API contract, log when the primary requirement is traceability, and lambda when the gateway must actively compute or decide. This keeps the integration aligned to the actual need instead of over-engineering the path.
Another way to frame it is by asking what must remain true at the boundary. If the receiver only cares that an event arrived, a webhook is enough. If it cares about the precise transport details, webhook-custom is the practical upgrade. If it cares about forensic history or later reconciliation, log is the better fit. If it cares about the pre-send logic itself, lambda is the right layer to hold that logic.
For teams operating at scale, consistency matters more than feature richness. A pattern that is easy to configure but hard to support will eventually cost more than a slightly less elegant one with a stable contract. The best implementations keep the webhook or lambda boundary narrow, document the expected request shape clearly, and avoid mixing audit, delivery, and business logic into the same mechanism.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Custom webhook requests depend on correct HTTP shape and headers. |
| Recommendation — Validate request configuration and enforce the exact HTTP shape the receiver expects. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Audit Events | Logging is the option explicitly aimed at auditability and traceability. |
| SC-8 — Transmission Confidentiality and Integrity | Webhook delivery and custom HTTP callbacks rely on protected transport and request integrity. | |
| Recommendation — Define and retain the event records needed for audit and later review. Protect callback traffic with authenticated, integrity-protected transport. | ||
Practitioner Guidance
What to verify: Confirm whether the downstream system truly requires a non-default HTTP method, header set, body format, or request signature before choosing webhook-custom. If not, standard webhook is usually the safer operational choice.
Decision rule: If the integration need is “send this event,” use webhook; if it is “send this event in a very specific HTTP shape,” use webhook-custom; if it is “record the event for later review,” use log; if it is “compute or route before sending,” use lambda.
Common mistake: Teams often reach for lambda when they really need request shaping. That adds unnecessary code paths, testing overhead, and failure handling for a problem that a custom webhook configuration could solve more cleanly.
Practitioner takeaway: The right pattern is the one that matches the boundary contract with the least transformation possible, because every extra layer increases operational complexity without improving the integration itself.
Related resources from NHI Mgmt Group
- When should teams use maintenance mode instead of custom time expressions?
- How do security teams decide when to use custom AI agents instead of fixed workflows for security operations?
- What breaks when security teams rely on polling instead of event-driven alert delivery?
- How do security teams decide when to use automation versus human review for AI-driven code changes?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
