Benchmark Email · AsyncAPI Specification

Benchmark Email Events

Version

View Spec View on GitHub Email MarketingCampaignsContactsAutomationTransactional EmailMarketingListSegmentationReportingDeliverabilitySending DomainsEmail TemplatesWebhookAgent ReadyAsyncAPIEvents

AsyncAPI Specification

Raw ↑
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.

Work with this as data

Every AsyncAPI spec here is available over the APIs.io API and to AI agents over MCP.

MCP server

One button, every client — Claude, Cursor, VS Code and the rest.

https://apis.io/mcp

Tools for asyncapi

4 MCP tools reach this
  • find_asyncapisBrowse and filter every AsyncAPI spec in the catalog.
  • apis_io_searchSTART HERE — APIs, providers and tags for one query, each with its total.
  • resolveTurn a domain, URL or GitHub org into the provider it belongs to.
  • find_cohortsEvery scored population of providers in the catalog.
All 92 tools →

Call it yourself

curl for this page
This AsyncAPI spec
curl "https://apis.io/api/v1/asyncapis/benchmark-email-events"
All asyncapi
curl "https://apis.io/api/v1/asyncapis?limit=25"

Discovery needs no key. Ratings and market analysis are Pro.

Get an API key

Free tier, no form to fill in. Signing in shares your email address with us — we store it to create your key and to recognise you if you sign in with another provider. See our Privacy Policy and Terms.

A second provider on the same verified email joins the account you already have.