Virto Commerce · AsyncAPI Specification
Virto Commerce Webhooks
Version
View Spec
View on GitHub
B2B E-CommerceCatalog ManagementOrder ManagementPricingInventoryShopping CartCustomer ManagementMarketingPaymentsShippingSubscriptionHeadless CommerceOpen-Source.NETWebhookEvent-DrivenCloudEventsGraphQLReturnsMCPB2B QuotesAsyncAPIWebhooksEvents
AsyncAPI Specification
generated: '2026-08-13'
method: searched
source: >-
https://github.com/VirtoCommerce/vc-module-webhooks (README, read 2026-08-13),
https://github.com/VirtoCommerce/vc-module-event-bus (README, read 2026-08-13),
openapi/virto-commerce-webhooks-api-openapi.yml and
openapi/virto-commerce-event-bus-api-openapi.yml (both harvested live from
https://virtostart-demo-admin.govirto.com/docs/<Module>/swagger.json on 2026-08-13)
asyncapi_published: false
asyncapi_note: >-
No AsyncAPI document is published by Virto Commerce — not in the GitHub organization, not on
the docs site, and not at /asyncapi.yaml on any host. None is fabricated here. What Virto
does publish is a fully-managed event surface with its own REST control plane, captured
below and in the two OpenAPI documents harvested in this pass.
description: >-
Virto Commerce ships TWO distinct, first-party event surfaces, and they are not the same
product. The Webhooks module delivers HTTP POST callbacks to endpoints an operator
configures. The Event Bus module forwards the same domain events to a message queue (Azure
Event Grid out of the box) as CloudEvents. Both discover their event catalog at RUNTIME by
reflecting over every DomainEvent/IEvent type in the installed modules, which is why no
static event list can be published: the catalog is a function of which of the ~100 modules a
given deployment has installed. Both are administered through REST, and both control-plane
APIs are now captured in openapi/.
surfaces:
- name: Webhooks
kind: HTTP callback delivery
module: https://github.com/VirtoCommerce/vc-module-webhooks
openapi: openapi/virto-commerce-webhooks-api-openapi.yml
transport: HTTP POST with a JSON-serialized event body
event_discovery: >-
Resolves all DomainEvent types from the platform and installed modules at runtime.
GET /api/webhooks/events (operationId WebHooks_GetAllRegisteredEvents) returns the live
catalog for a given deployment.
event_catalog_captured: false
event_catalog_note: >-
GET /api/webhooks/events returned HTTP 401 on an anonymous probe of the reference
deployment (2026-08-13). The event list is authenticated and deployment-specific, so no
event names are asserted here.
payload_composition: >-
Selective — a webhook subscription names the specific entity properties to include in the
body, with access to PREVIOUS values for change tracking. GET /api/webhooks/properties
(WebHooks_GetEventObjectProperties) enumerates the selectable properties for an event.
authentication_to_endpoint:
- None
- HTTP Basic
- Bearer Token
- Custom Header
signing: >-
No HMAC payload signature is offered. Receiver-side authenticity relies on the shared
Basic/Bearer/custom-header credential the operator configures — weaker than a signed-body
scheme, and worth knowing before building a public receiver.
delivery:
retries: 3 (configurable via Webhooks.General.SendRetryCount)
backoff: exponential, 2^(n-1) minutes — 1, 2, 4
engine: Polly retry policy over Hangfire background jobs
debounce: 5 seconds
batch_size: 20
observability:
feed: >-
Every attempt — success or failure — is persisted as a WebhookFeedEntry recording
request/response headers, body, HTTP status, error message and attempt count.
api: POST /api/webhooks/feed/search (WebHooks_SearchWebhookFeed)
retention: Webhooks.General.LatestErrorCount (default 5 recent errors per webhook)
manual_trigger: POST /api/webhooks/send (WebHooks_Run)
permissions:
- webhooks:access
- webhooks:read
- webhooks:update
- webhooks:delete
- webhooks:feed:read
operations:
- WebHooks_Search
- WebHooks_GetWebhookById
- WebHooks_SaveWebhooks
- WebHooks_DeleteWebHooks
- WebHooks_Run
- WebHooks_GetAllRegisteredEvents
- WebHooks_GetEventObjectProperties
- WebHooks_SearchWebhookFeed
- WebHooks_DeleteWebHookFeeds
- name: Event Bus
kind: message-queue forwarding
module: https://github.com/VirtoCommerce/vc-module-event-bus
openapi: openapi/virto-commerce-event-bus-api-openapi.yml
transport: provider connection — Azure Event Grid built in, pluggable provider model
data_format: CloudEvents
data_format_evidence: >-
"the Azure Event Grid provider emits events using the CloudEvents specification" — module
README.
event_discovery: >-
Scans all loaded assemblies at startup and exposes every IEvent implementation as
subscribable. GET /api/eventbus/events (Subscriptions_Get) returns the live catalog;
anonymous probe returned HTTP 401 (2026-08-13).
filtering: JsonPath expression per subscription (JsonPathFilter, default "$" = match all)
transformation: Scriban/Liquid template per subscription (PayloadTransformationTemplate)
configuration_sources:
- appsettings.json (EventBus:Connections, EventBus:Subscriptions)
- runtime via REST API (database-backed)
observability: >-
Failed deliveries persist as provider connection logs with status, error message and
payload — POST /api/eventbus/logs/search.
operations:
- Connections_SearchConnections
- Connections_GetConnectionByName
- Connections_CreateConnection
- Connections_UpdateConnection
- Connections_DeleteConnection
- Subscriptions_Get
- Subscriptions_SearchSubscriptions
- Subscriptions_GetSubscriptionById
- Subscriptions_CreateSubscription
- Subscriptions_UpdateSubscription
- Subscriptions_DeleteSubscription
- ConnectionsLog_SearchProviderConnectionLog
related:
- name: Push Messages
module: https://github.com/VirtoCommerce/vc-module-push-messages
note: >-
In-app notification fan-out to storefront users, surfaced in the xAPI as pushMessages
queries and a Subscriptions root type in the GraphQL SDL. Operator-to-user messaging, not
a system integration event surface.
- name: Notifications
module: https://github.com/VirtoCommerce/vc-module-notification
note: Templated email/SMS delivery, not a webhook surface.
gaps:
- No AsyncAPI document, so the event surface is not machine-readable as an event contract.
- No published static event catalog — the list is per-deployment and requires an authenticated call.
- No payload signing (HMAC) on outbound webhooks.
- No documented replay/dead-letter mechanism beyond the retry policy and the audit feed.