013 events · delivered immediately
Happy path
Three valid events are accepted and delivered on the first attempt.
RelayBench
RelayBench demonstrates how a webhook delivery service validates, routes, retries, and records events. Visitors can run predefined scenarios, inspect every delivery attempt, and ask a grounded AI investigator to diagnose the final result.
ContractsJSON Schema 2020-12
DeliveryAt least once
Infrastructure as codeTerraform
AI investigationAmazon Bedrock
01 — Live demoOpen full demo
Choose a bounded failure scenario, follow its delivery attempts, then run the AI investigation after the event reaches a terminal state. The model is invoked only when you request a diagnosis.
If the embedded application does not load, you can open RelayBench in a new tab.
02 — ArchitectureREQUEST TO RESULT
- Scenario APICreates predefined test events
- EventBridgeRoutes supported event types
- SQSQueues deliveries and failed messages
- LambdaProcesses each delivery attempt
- DynamoDBStores runs, attempts, and results
The interface is served through CloudFront and sends requests to API Gateway. Visitors can run predefined scenarios, while a separate IAM-authorized endpoint accepts signed events for integration testing. Accepted events move through EventBridge and SQS before a Lambda function records the delivery result in DynamoDB.
03 — ScenariosAVAILABLE TEST CASES
022 failed attempts · then success
Retry, then success
The receiver fails twice before accepting the third delivery attempt.
03Repeated event · stored once
Duplicate delivery
The same event is sent twice to show how duplicate deliveries are detected.
04Rejected before publication
Invalid schema
An event with a missing required field is rejected before it enters the queue.
053 failed attempts · moved to DLQ
Permanent failure
A delivery that continues to fail is moved to the dead-letter queue.
04 — AI investigationGROUNDED INCIDENT TRIAGE
Evidence first, model second
The model receives only server-generated facts from a completed run. It cannot see arbitrary visitor instructions, invent new evidence IDs, or choose a diagnosis outside the application's allowlist.
RelayBench validates the model's structured response, resolves every citation against the supplied evidence, and compares the diagnosis with the scenario's known outcome. The interface exposes token usage, latency, prompt version, and whether the result came from Bedrock or the cache.
Diagnoses are explicitly requested, cached per run, limited to one concurrent model invocation, and protected by a monthly application-level allowance to keep the demo within its operating budget.
05 — ContractsSCHEMA MANAGEMENT
Event contracts and versioning
RelayBench defines three event types with JSON Schema: customer creation, subscription activation, and invoice payment failure. Each CloudEvents-compatible envelope includes the event ID, source, type, subject, timestamp, and schema.
Existing schema versions are not changed after release. Breaking contract changes require a new event version, while optional fields can be added to the current version. OpenAPI documents the HTTP endpoints, and AsyncAPI documents the events.
06 — Implementation choicesWHY THESE COMPONENTS
Separate routing from delivery
EventBridge routes each supported event type. SQS holds delivery work and handles retries and failed messages, so routing rules remain separate from processing.
Expect repeated messages
Queue messages can be delivered more than once. The consumer records each event by source and ID before updating the run, preventing duplicate results.
Keep public input controlled
Public visitors can run predefined scenarios but cannot submit arbitrary payloads or webhook URLs. Signed AWS requests use the separate producer endpoint.
Keep delivery history visible
Each run stores its events, individual attempts, response status, and final state. The interface polls the read API so visitors can follow retries as they happen.