Skip to main content

Notification Test Endpoints

Summary​

Two verification hooks are mapped alongside the administration group. POST /notifications/test/dispatch drives an event synchronously through the dispatcher without a broker; POST /notifications/test/publish places the event on the bus so the hosted consumer round-trips it.

Audience​

Engineers, QA, architects, support and security reviewers.

Reference Content​

The verified reference material for this topic is set out in the sections below.

Testing architecture​

POST /notifications/test/dispatch​

Constructs a NotificationEventEnvelope in process and passes it straight to INotificationDispatcher.DispatchAsync. No broker is required.

Verified request fields: eventType (required), eventId, correlationId, tenantId, sourceService, forceFail and occurredAtUtc, plus a free-form JSON payload.

Verified defaults: a missing eventId becomes a newly generated identifier; a blank correlationId becomes a generated compact identifier; a blank sourceService becomes the literal test source name; a missing occurredAtUtc becomes the current instant; a missing payload becomes an empty JSON object. The envelope schema version is fixed at one.

Validation: a blank eventType returns 400 with a message object.

Response (verified): the event identifier, correlation identifier, event type, the dispatch outcome rendered as its enumeration name, and the identifiers of any messages created.

POST /notifications/test/publish​

Publishes the same logical event onto the integration-events bus through IEventBus.PublishAsync, exercising the hosted consumer path end to end.

Verified metadata written: event identifier, event type, correlation identifier, source service, tenant identifier, occurrence timestamp in round-trip format, and a fixed schema version of one. When forceFail is set, the forced-failure header is added to the metadata.

Validation: a blank eventType returns 400 with a message object.

Response (verified): on success, the event identifier, correlation identifier, event type and a published flag. When the bus reports that publication did not succeed, the handler returns bare status 502 with no body.

This is the only endpoint in the entire native surface that returns a 5xx status deliberately.

Forced-failure flag​

Both hooks accept forceFail. The dispatch hook carries it on the envelope; the publish hook carries it as a message header. Every channel sender honours it, which makes the failure and retry paths deterministically reproducible without breaking a real provider.

Exposure posture​

Both hooks are mapped unconditionally. There is no environment guard, no configuration switch and no authorization requirement that would restrict them to non-production hosts. A caller reaching the service can inject arbitrary event types and payloads into the notification pipeline, and can publish arbitrary messages onto the shared integration-events exchange.

This is recorded as a verified limitation.

Classification​

Implemented; unconditional exposure is a verified limitation.

Requires confirmation​

Whether these hooks are intended to be reachable in production, and whether an environment guard is planned, require confirmation.

See Also​

Keywords​

  • Notification API
  • Test Endpoints
  • Draft API documentation

Source References​

  • microservices/src/notification-service/Api/NotificationEndpoints.cs
  • microservices/src/notification-service/Messaging/NotificationEventEnvelope.cs
  • microservices/src/notification-service/Messaging/NotificationEventConsumer.cs
  • microservices/scripts/smoke-notification.ps1

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-21
  • Review cycle: Quarterly