Skip to main content

Notification API Limitations

Summary​

Every limitation below is a verified property of the reviewed source, not a projection. Each is grouped by the concern it affects and cross-referenced to the page that documents the evidence.

Audience​

Engineers, architects, QA, support, security reviewers, DevOps engineers and product owners.

Reference Content​

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

Authentication​

  • No authentication scheme is registered in the native service; all 17 native endpoints are anonymous.
  • No native handler reads a claims principal, so no caller identity is available in service code.
  • The recipient identifier on the inbox endpoint is caller-supplied and never checked against an authenticated subject.
  • Authentication exists only on the compatibility surface, making it a property of the routing path rather than of the module.

Authorization​

  • No authorization services, policies or role requirements are registered in the native service.
  • No native single-record operation performs an ownership check; knowledge of an identifier is sufficient to read a message, mark it read, retry it, or update a template.
  • The failed queue, audit trail and statistics endpoints return data spanning all tenants to any caller that can reach the service.
  • Administrative operations share the /notifications path prefix with the recipient-facing inbox, so no path-based separation exists between operator and employee functions.
  • The compatibility template operations require authentication but declare no role requirement, so any authenticated caller may modify templates.
  • Portal permission and role hints have no verified server-side counterpart.

Validation​

  • No validation framework, filter or attribute is registered; only four hand-written guard clauses exist across the surface.
  • No DTO declares any validation attribute, required modifier or format constraint.
  • No format check exists on the destination address accepted by the template test endpoint.
  • No schema is enforced on the free-form JSON payload accepted by both test hooks.
  • Out-of-range page sizes are silently clamped rather than rejected, so a caller receives a different page size than requested without notice.
  • No body-size limit, content-type restriction or rate limit is declared on any endpoint.

Gateway​

  • The generated /api/notifications prefix route declares no path transform, while the native service maps nothing under the /api prefix — path alignment for the toggle-on path requires confirmation.
  • The notification-templates prefix is not in the toggle's owned-prefix set, so the template surfaces cannot be migrated together with the notification surface by the existing toggle.
  • The shadow route uses the bare /notifications prefix rather than a service-named prefix, sharing a namespace with monolith paths at the gateway.
  • No authentication requirement is declared on the notification route entries themselves.

Compatibility​

  • Two implementations coexist with incompatible contracts: GUID versus integer identifiers, versioned channel templates versus event-key templates, status values versus boolean read flags.
  • The native service exposes no monolith-shaped compatibility endpoints, unlike other extracted modules in this platform, so no adapter reconciles the two contracts.
  • Only the shadow route reaches the native surface with paths that match its route table.
  • The portal calls the legacy paths for user-facing notification and template functions while an operations dashboard reads native administration paths, so both surfaces are live consumers simultaneously.

Delivery​

  • The template test endpoint performs exactly one delivery attempt and does not use the bounded retry loop that event-driven delivery uses.
  • A failed test send returns 200 with the failure described in the body, so status-code-based error handling will not detect it.
  • The retry endpoint does not require the message to be in a failed state.
  • No endpoint reports delivery outcome per channel, bulk-retries the failed queue, or exposes provider health.
  • The synchronous dispatch hook holds the HTTP request open through the dispatcher's retry delays.

Response and error contract​

  • No named response DTO exists on the native surface; responses are serialized persistence entities or anonymous projections, coupling the wire contract to the storage model.
  • No uniform response envelope applies across the surface — only the service-information endpoint uses the platform envelope.
  • Collections return bare arrays with no total count or continuation token, so a caller cannot detect truncation.
  • No exception-handling middleware and no problem-details contract is registered; four distinct error shapes exist on one surface.
  • The template test path echoes a raw exception message back to the caller.
  • No Produces metadata is declared, so the generated document infers schemas and cannot name the anonymous projections.

Testing​

  • No automated API test project, contract test or framework-based assertion suite exists.
  • The smoke script covers 15 of 17 native endpoints on the happy path only — no negative-path, not-found, publish-failure, clamping, correlation-header or tenant-isolation assertions.
  • The service-information and health endpoints are not exercised by any automated artifact.
  • Authorization cannot be tested until enforcement exists.

Versioning​

  • HTTP API versioning is entirely absent — no route segment, header, query parameter, media type, attribute or versioned document.
  • No deprecation or sunset signalling exists on any route.
  • A breaking change would reach every caller simultaneously with no negotiated migration path.
  • The template version and event schema version fields are internal concepts and are not selectable through the API.

Operational exposure​

  • The Swagger document and UI are enabled unconditionally, not gated on environment.
  • Both test hooks are mapped unconditionally, allowing arbitrary event injection into the pipeline and arbitrary publication onto the shared integration-events exchange.
  • The health endpoint registers no individual checks, so a healthy response confirms only that the HTTP host is responding.

Classification​

Verified limitations. The module is Transitional; authentication, authorization and versioning on the native surface are Not implemented; validation, response contracts, health and testing are Partial.

Requires confirmation​

Deployment-level enforcement of access control, the intended canonical surface, the toggle-on path alignment, and whether the operational exposures above are accepted for production require confirmation.

See Also​

Keywords​

  • Notification API
  • API Limitations
  • Draft API documentation

Source References​

  • microservices/src/notification-service/Api/NotificationEndpoints.cs
  • microservices/src/notification-service/Program.cs
  • microservices/src/gateway-api/Program.cs
  • microservices/scripts/smoke-notification.ps1
  • Controllers/NotificationsController.cs
  • Controllers/NotificationTemplatesController.cs

Revision Information​

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