Notification DTO Catalog

Summary

The native surface declares four request DTOs and no response DTOs — responses are either serialized domain entities or inline anonymous projections. The shared kernel contributes two response types. The compatibility surface declares five DTOs. Total verified data-transfer types: eleven.

Audience

API consumers, engineers, architects, QA, support, security reviewers and implementation partners.

Reference Content

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

Native request DTOs

All four are declared as sealed classes in NotificationEndpoints.cs and bound from the JSON request body.

`CreateTemplateRequest`

Purpose: create the next template version for a tenant, key and channel.
Direction: request.
Fields: tenant identifier, template key, channel, subject template, body template, locale, description and an active flag. Template key and channel are non-nullable with empty-string defaults; the rest are nullable.
Validation: the handler requires a non-blank template key and a non-blank, known channel. No attribute-based validation is declared on the type.
Source: microservices/src/notification-service/Api/NotificationEndpoints.cs

`UpdateTemplateRequest`

Purpose: partially update an existing template row.
Direction: request.
Fields: subject template, body template, locale, description and an active flag — every field nullable, which is what makes the update partial.
Validation: none declared. Null fields are skipped rather than rejected.
Source: microservices/src/notification-service/Api/NotificationEndpoints.cs

`TestTemplateRequest`

Purpose: render a template, optionally performing one live delivery.
Direction: request.
Fields: a string-to-string variables dictionary, a send flag and a destination address — all nullable.
Validation: none declared. A null variables dictionary is replaced with an empty one; the live-send path is taken only when the send flag is true and the address is non-blank.
Source: microservices/src/notification-service/Api/NotificationEndpoints.cs

`TestPublishRequest`

Purpose: shared request type for both test hooks.
Direction: request.
Fields: event type, event identifier, correlation identifier, tenant identifier, source service, a forced-failure boolean, an occurrence timestamp and a free-form JSON payload element.
Validation: the handlers require a non-blank event type. Every other field is defaulted when absent.
Note: the payload is carried as a raw JSON element, so no payload schema is enforced or declared at the API boundary.
Source: microservices/src/notification-service/Api/NotificationEndpoints.cs

Native response types

The native surface declares no dedicated response DTO. Responses fall into two categories.

Serialized domain entities — returned directly from the persistence model: the template entity from list, create and update; the message entity from single-message read and the failed queue; the delivery-attempt entity from the attempts endpoint; the processed-event entity from the idempotency lookup; and the audit-log entity from the audit query. These are declared in Domain/NotificationEntities.cs.

Returning persistence entities directly means the wire contract is coupled to the storage model, and every entity field is exposed. This is recorded as a limitation.

Inline anonymous projections — constructed in the handler and never named: the inbox item projection, the read-state projection, the retry-status projection, the statistics projection, the template render result, the dispatch outcome, the publish acknowledgement, and the several small not-found and bad-request objects.

Because they are anonymous, none of these shapes has a schema name, and none can be referenced from a generated client.

Shared response types

`ApiResponse<T>`

Purpose: the platform standard response envelope.
Direction: response.
Fields: success flag, message, nullable data, nullable correlation identifier and a nullable errors dictionary keyed by field name.
Usage in Notification: used by the service-information endpoint only. No other Notification endpoint wraps its response in this envelope.
Source: microservices/src/contracts/Common/ApiResponse.cs

`ServiceInfoResponse`

Purpose: service identity payload.
Direction: response.
Fields: service name, description, environment name and a timestamp.
Source: microservices/src/contracts/Common/ApiResponse.cs and the shared-kernel endpoint extension.

Compatibility DTOs