Benchmark Email · AsyncAPI Specification
Benchmark Email Events
Version
View Spec
View on GitHub
Email MarketingCampaignsContactsAutomationTransactional EmailMarketingListSegmentationReportingDeliverabilitySending DomainsEmail TemplatesWebhookAgent ReadyAsyncAPIWebhooksEvents
AsyncAPI Specification
generated: '2026-08-13'
method: searched
source: >-
https://developers.benchmarkemail.io/openapi.json (event type enums on GET
/api/contact/events) and
https://github.com/BenchmarkEmail/RESTful-API-v3/tree/master/Use%20Cases%20and%20Solutions%20Sandbox
(classic v3.0 webhook payload flags), read 2026-08-13
name: Benchmark Email Event and Webhook Surface
description: >-
Benchmark Email has an event surface on both of its APIs, but publishes NO AsyncAPI
document for either — searched /asyncapi.yaml, /asyncapi.json, the developer docs index
(llms.txt) and the GitHub account, all miss. The two surfaces work in opposite
directions: the classic v3.0 API PUSHES to a webhook URL you register per list, while the
new v1 API offers no webhooks at all and instead exposes a PULL event feed you poll. An
integration that moves from classic to v1 loses push delivery.
asyncapi_published: false
asyncapi_searched:
- url: https://developers.benchmarkemail.io/asyncapi.json
status: 404
- url: https://developers.benchmarkemail.io/asyncapi.yaml
status: 404
surfaces:
- name: Benchmark Email v1 contact event feed
style: pull
api: benchmark-email:benchmark-email-api
transport: HTTPS polling
operations:
- operationId: get_api_contact_events
path: GET /api/contact/events
summary: Get all contact events for the account
scope: contacts:read
- operationId: get_api_contact_by_contactId_events
path: GET /api/contact/{contactId}/events
summary: Get events for a single contact
scope: contacts:read
delivery_note: >-
Read-only. There is no subscription, no callback registration and no signature to
verify — the consumer polls and filters by event type. Nothing in the v1 OpenAPI
declares a webhooks or callbacks block.
event_types:
- id: contact-created
domain: contact
- id: contact-updated
domain: contact
- id: contact-update-failed
domain: contact
- id: contact-unsubscribed
domain: contact
- id: contact-reactivated
domain: contact
- id: email-sent
domain: email
- id: email-delivered
domain: email
- id: email-bounced
domain: email
- id: email-delayed
domain: email
- id: email-rejected
domain: email
- id: email-complaint
domain: email
- id: email-opened
domain: email
- id: email-clicked
domain: email
- id: email-skipped
domain: email
first_touch_event_types:
note: >-
A reduced enum used where only the first occurrence per recipient is reported.
values:
- email-sent
- email-delivered
- email-bounced
- first-contact-unsubscribed
- first-email-complaint
- first-email-opened
- first-email-clicked
- name: Benchmark Classic v3.0 webhooks
style: push
api: benchmark-email:benchmark-email-webhooks-api
transport: HTTP POST to a customer-supplied ClientUrl
scope_of_subscription: per contact list (ContactMasterID)
operations:
- operationId: post__contact__listid__webhooks
path: POST /Contact/{ListID}/Webhooks
summary: Create a webhook for a list
- operationId: get__contact__listid__webhooks
path: GET /Contact/{ListID}/Webhooks
summary: List webhooks on a list
- operationId: patch__contact__listid__webhooks__id
path: PATCH /Contact/{ListID}/Webhooks/{ID}
summary: Update a webhook
- operationId: delete__contact__listid__webhooks__id
path: DELETE /Contact/{ListID}/Webhooks/{ID}
summary: Delete a webhook
subscription_model: >-
One webhook record carries five independent boolean flags, each "1" to subscribe and
"0" to ignore. A single registration can therefore cover several event types.
event_flags:
- flag: Subscribes
meaning: A contact subscribed to the list.
- flag: Unsubscribes
meaning: A contact unsubscribed from the list.
- flag: EmailChanged
meaning: A contact's email address changed.
- flag: ProfileUpdates
meaning: A contact field value changed.
- flag: CleanedAddress
meaning: An address was cleaned (hard bounce or invalid) off the list.
payload_fields:
- ClientUrl
- ContactMasterID
security:
signature_verification: none published
replay_protection: none published
note: >-
The classic webhook documentation specifies no signing secret, no HMAC header and no
timestamp — a receiver cannot verify that a POST came from Benchmark Email other than
by keeping the ClientUrl secret. This is a real gap worth reporting to the provider.
gaps:
- >-
No AsyncAPI document for either surface, so the event catalog above had to be recovered
from an OpenAPI enum and a GitHub markdown example rather than read from a contract.
- >-
The new v1 API has no webhooks. Fourteen event types are enumerated and readable only by
polling, which is a step back from the classic push webhooks for any integration that
needs low latency.
- >-
No webhook signature scheme is published for the classic surface.