Product

Changelog

Choosing what a test message sends

  • Test messages (POST /v1/endpoints/{id}/test, the dashboard, the customer portal, the MCP tool send_test and SDKs) take an optional payload (a JSON object, up to 1 MB). It is sent as the message data, with transformations, payload format and signatures applied just like a real delivery. Test messages do not count toward your monthly quota
  • Test messages and connection tests to chat endpoints (Slack, Microsoft Teams, Chatwork and Google Chat) post a readable “Test message” title and text, in the organization’s notification language (Japanese or English). Webhook and polling endpoints still receive { test: true, endpoint_id }
  • Fixed deliveries to Google Chat endpoints failing with invalid_output when the transformation does not change the URL

Google Chat endpoints

  • New endpoint type: Google Chat (a space’s incoming webhook, google_chat). Pro plan and above; dashboard, customer portal, API, MCP and SDKs
  • The post is built from title, text, lines and link in the message data (up to 4,000 characters). Errors that retrying cannot fix, such as a deleted webhook (401, 403, 404), disable the endpoint

Polling endpoints from the browser

  • GET /v1/poller/{id} can now be called directly from a browser (CORS, any origin). Pass the token in the Authorization header

Dashboard guide and archiving event types

  • Published the dashboard guide (/en/docs/guide/) and added “Guide” to the dashboard’s side menu
  • Edit an event type’s description, archive it and unarchive it from the dashboard (Admin and above)
  • Deliveries in the message details now include max_attempts, and the dashboard shows attempts as “n / max” (dashboard, API and customer portal)
  • Fixed bulk retries in Enterprise organizations rejecting every time range
  • Adding and removing alert channels and changing alert conditions are now shown only to Admins and above

Japanese by default and MCP sign-in only

  • The site now defaults to Japanese, with English pages under /en/. Old /ja/… URLs redirect to the same page (301)
  • Emails and screens for accounts and organizations that have not chosen a language are in Japanese (English if the browser prefers English). A language you have chosen stays as it is
  • The MCP server now accepts sign-in (OAuth) only. Connections with an API key get a 401. Use the public API or SDKs from CI and scripts
  • Secrets in endpoint URLs (such as Google Chat’s key and token, and Slack and Discord webhook URLs) are masked in audit logs, alert notifications and emails

Consumption tax on invoices

  • Invoices now add consumption tax (10%). Listed prices exclude tax, and the plan change confirmation shows the tax included in the amount due

Retrying to disabled endpoints and delivery error values

  • Manual retries and test messages to a disabled endpoint now return 409 endpoint_disabled. Fix the endpoint and re-enable it, then retry. Retries to a deleted endpoint return 404 (dashboard, customer portal, API, MCP and SDKs)
  • Endpoints disabled automatically now show an “Enable” button in the dashboard and customer portal. Deliveries in the message details include the endpoint’s status (endpoint_status)
  • Delivery errors are recorded as fixed values (timeout, connect_failed, dns_failed, blocked_ip, relay_failed). The API returns older records unchanged

Slack, Microsoft Teams and Chatwork endpoints

  • New endpoint types: Slack, Microsoft Teams and Chatwork. Pro plan and above; dashboard, customer portal, API, MCP and SDKs
  • The post is built from title, text, lines and link in the message data, or shows the event type and JSON when those are missing. Errors that retrying cannot fix, such as a wrong token, disable the endpoint and record the reason. On 429 we retry after Retry-After

Deleting customers and messages with no endpoint

  • Delete a customer (DELETE /v1/consumers/{id}, the customer list in the dashboard and SDKs). Its endpoints, signing secrets and sources are deleted with it, customer portal links stop working immediately, and undelivered messages are not sent
  • Messages that had no endpoint to go to when they were accepted (the customer has no endpoint, or none of its endpoints takes the event type) now have the status no_endpoint (“No endpoint”) instead of pending. Messages accepted earlier show as no_endpoint too (dashboard, API, MCP and SDKs)
  • These messages are stored but not sent, and they are not counted in your monthly quota, sent counts, pending or retry backlog. Adding an endpoint later does not send them
  • The message status in the API has one more value. If you branch on status, handle no_endpoint as well. Filter the list with status=no_endpoint
  • New MCP tool list_messages lists messages, filterable by status, event type and customer

Migrating from other services

  • Pass the signing secret you already use (whsec_…) as secret when creating an endpoint, so receivers keep their secret (API, MCP and SDKs)
  • Choose the body shape per endpoint (body_format). raw sends data as is, without the { type, timestamp, data } envelope (dashboard, customer portal, API, MCP and SDKs)
  • Transformations get webhook.env (saved variables), webhook.transformationsParams (the message’s transformations_params) and an on/off switch (enabled). Code can be up to 51,200 characters
  • Compatible transformation routes (/api/v1/app/{app_id}/endpoint/{id}/transformation and …/simulate). Errors on these routes come back as { code, detail } in English

Polling endpoints

  • Create endpoints without a URL (type: polling). The receiver fetches messages in order with the endpoint’s token via GET /v1/poller/{id} (read on with an iterator; Starter plan and above; dashboard, customer portal, API, MCP and SDKs)
  • Payloads, IDs and signatures are the same as pushed webhooks. Polling again acknowledges the previous page, which shows as fetched in the logs
  • Get a failure alert when no one polls an endpoint for the time you choose (24 hours by default)
  • Compatible poller routes (/api/v1/app/{app_id}/poller/{id}, per-customer positions, token get and rotate) and the pollingEndpoint type are accepted too

Destinations other than webhooks

  • New endpoint types: Amazon SQS, Amazon EventBridge, Google Cloud Pub/Sub, Amazon S3, Cloudflare R2, Google Cloud Storage, Azure Blob Storage, Azure Service Bus, Kafka (Confluent REST) and RabbitMQ (HTTP API) (Pro plan and above; dashboard, API, MCP, SDKs and customer portal)
  • The body is the same Standard Webhooks JSON, with the signature and IDs in message attributes or object metadata. Retries, ordered delivery, transformations, failure alerts and the static source IP work as for webhooks
  • Credentials are stored encrypted; the dashboard and API show only a masked hint. Test a destination by sending one message before saving
  • Create destinations through a compatible route (POST /api/v1/app/{app_id}/destination); type names such as eventBridge are accepted too

Transformations

  • Save a JavaScript handler(webhook) per endpoint to change the payload, headers, URL path and query or method right before delivery, or to skip the delivery (Pro plan and above; dashboard, API, MCP and SDKs)
  • The signature covers the transformed body. Deliveries skipped by a transformation show as cancelled and do not count as failures
  • Try a transformation against a sample payload in the dashboard without sending anything

Sources and ordered delivery per endpoint

  • New: sources, for receiving webhooks from other services (Stripe, GitHub, Shopify, Slack, Meta, Zoom, LINE, Standard Webhooks, custom HMAC signatures, Basic authentication and API keys). Webhooks sent to a source’s ingress URL are verified, then delivered to the endpoints of the customer you choose (dashboard, API and MCP)
  • Accepts POST, PUT, PATCH and DELETE with bodies up to 10 MB. The only per-source limit is an abuse cap of 1,000 requests per 10 seconds
  • Redeliveries from the other service are merged into one message by delivery ID, and every request is kept in the source’s request log (GET /v1/sources/{id}/requests)
  • A paused source accepts and holds requests, and delivers them in the order received when it resumes
  • Endpoints with body_format: raw receive the original body byte for byte with its original Content-Type. Choose received headers to pass on (forward_headers) and set the response returned on accept (response)
  • Reprocess rejected requests after fixing the signing secret or settings (POST /v1/sources/{id}/requests/{request_id}/reprocess, dashboard and MCP)
  • Sources per organization: Free 1, Starter 5, Pro 20, Business unlimited
  • New per-endpoint setting to deliver messages one at a time, in the order they were accepted (ordering: fifo, in the dashboard, API, MCP and customer portal). The next delivery waits until the previous one is delivered or ends as failed
  • While later deliveries wait behind a failing one, failure alerts show how many are waiting. Endpoint details show the count (waiting_count)

Log search, sending limits and new prices

  • New storage format for delivery logs (records from September 28)
  • Log search now matches the message ID, event type, customer and Idempotency-Key (full-text search of payloads has ended)
  • Filtering by status, event type or customer, and search, cover the last 7 days unless you set a time range (dashboard, customer portal and API). GET /v1/messages now accepts since
  • Test environments and test sends: up to 1,000 messages per environment per day (UTC), combined
  • Up to 20 endpoints per customer
  • Free organizations: up to 3 members, pending invites included (unlimited from Starter)
  • Deliveries to an endpoint that keeps failing are held for a while and counted as retries without being sent, then retried per the endpoint’s retry policy (they end as failed when retries run out)
  • New prices: Pro $199 / month, Business $650 / month, and overage $2.00 per 100,000 messages (Starter stays at $20 / month)

Webhook Admin launched

  • Sending API (POST /v1/messages) and APIs for customers, endpoints, event types and logs
  • Signatures in the Standard Webhooks format
  • Automatic retries (by default up to 8 attempts including the first, over about 28 hours; the count and interval can be chosen per endpoint) and automatic disabling of endpoints failing for 5 days
  • Bulk resend per endpoint, and a compatibility signature for receivers that verify a custom signature
  • Static source IP (Starter and up)
  • Failure alerts (Slack, Teams, Chatwork, email, webhook) with selectable conditions
  • Organizations, projects, production and test environments, and a view across all projects
  • Embeddable customer portal
  • MCP server