DOCUMENTATIONv2

POST

Notifications

Push new notification

/api/v2/notifications/push

AUTHENTICATIONBearer token · service:notifications:publishAUTHORITATIVE OWNERnotificationsCONTRACT AUTHORITYCapability registry · plannedSTATUSPlanned · not executable

PLANNING CONTRACT · NOT CALLABLE

This page describes intended capability and integration boundaries so people and agents can prepare safely. Do not send this request or register it as an executable tool. Wait until the capability registry marks it implemented-contract, then re-fetch the deployed OpenAPI document and build the request from that machine contract.

PURPOSE + BUSINESS CONTEXT

Planned capability: apply the requested transition to push new notification through the authoritative notification service boundary.

WHEN THIS CALL IS USEFUL

Do not call or register this operation as an executable agent tool yet. Use this page to plan the future push new notification workflow; enable it only after the status becomes implemented-contract and the exact operation appears in deployed OpenAPI.

OUTCOME · Planned · Create or advance

What changes

None today: this route is not executable. Its intended behavior is: no executable public behavior exists. Promotion would create an owner-targeted signal only; it must not perform or authorize the referenced domain action.

WHY IT MATTERS

Lets people and agents prepare for push new notification without falsely presenting roadmap scope as a live capability.
Gives people and agents a contract-backed way to advance push new notification.
Provides a bounded attention queue with stable references and unread state while preserving the owning domain as the authority for any consequential action.

ISOLATION + AUTHORITY

Profile, workspace, notification, delivery channel, read or archive status, referenced resource, and owning-domain lifecycle remain distinct. Reading, marking, or archiving a signal changes only inbox presentation state and never authorizes, executes, reverses, or resolves the referenced business action. This planning record grants no runtime authority, and only deployed OpenAPI can define an executable public contract.

BEFORE YOU CALL

First confirm that this operation is marked implemented-contract and exists in the currently deployed OpenAPI document; until then, no production request is valid.
Its capability-registry profile is provisional integration guidance, not an executable request schema.
Authenticate at the documented boundary: bearer.
Treat the proposed event (body) as planning input only; re-generate the request from deployed OpenAPI before making a call.
Use one Idempotency-Key only for retries of the same byte-equivalent logical mutation.
Resolve the authenticated profile and workspace plus the canonical resource reference and owning domain for any signal that may require action.

WHAT TO DO NEXT

Keep this operation disabled in clients, agents, SDKs, and workflow automation while it remains planned-contract.
Use the stated owner, lifecycle, authority boundary, and provisional push new notification profile to prepare requirements and conformance tests without sending a request.
Monitor the capability registry for implemented-contract, then re-fetch deployed OpenAPI and validate its exact security, parameters, schemas, responses, and agent metadata before enabling the integration.

AGENT GUIDANCE

Never call this planned contract, include it in an executable tool registry, or infer runtime availability from this readable page.
Its capability-registry profile is provisional integration guidance, not an executable request schema.
Use push new notification only for the purpose and lifecycle stage described by this operation; do not treat it as authority for an adjacent action.
Treat the proposed event (body) as planning input only; re-generate the request from deployed OpenAPI before making a call.
Distinguish signal delivery, unread state, acknowledgement, archival, referenced-resource state, and resolution in the authoritative domain workflow.
After a timeout or conflict, read authoritative state before deciding whether an equivalent retry is safe.
When implementation lands, discard generated requests based on this planning record and rebuild them from the deployed OpenAPI operation.

MACHINE CONTRACT

This operation is a non-executable planning contract. Its capability-registry record defines the intended owner, parameters, responses, and integration boundary until an implemented Rust OpenAPI operation replaces it.

EXTENDED INTEGRATION GUIDANCE

Readable request and response reference

Examples describe the reviewed planning contract and remain non-executable until promoted into OpenAPI.

PARAMETERS

Headers, path, query, and body

NAMELOCATIONPRESENCETYPE / RULES / PURPOSE

eventbodyRequired

future authenticated typed service eventPlanning profile only; no executable request schema or user-bearer publisher exists.

REQUEST

JSON body example

{
  "event": "NOT EXECUTABLE — discover status through GET /api/v2/capabilities"
}

RESPONSES

Status and payload examples

501Planning contract only; absent from live OpenAPI.Not executable · JSON RESPONSE+

{
  "code": "planned_contract",
  "message": "No public notification publisher is available."
}

INTEGRATION DECISIONplanned_contract

CALLER ACTION: Do not send this request or register it as an executable agent tool. Use the implemented alternatives linked by the module guide.
RETRY SAFETY: Do not retry on a timer. Re-fetch production OpenAPI and proceed only after this exact operation appears there.
STATE RECONCILIATION: No runtime state exists to reconcile for this planning contract. Continue from the authenticated profile, tenant brand, referral, funding, and account-lifecycle projections through an implemented operation.
ESCALATE WHEN: Escalate when a fresh session resolves to an unexpected tenant or profile, or when an account lifecycle receipt cannot be found after reconciliation.

OPERATIONAL NOTES

Security and lifecycle guarantees

Do not call or generate a client for this route. Only operations present in the live OpenAPI document are executable.
Promotion requires a separately authenticated domain-service publisher, allowlisted typed events, server-derived target ownership, display-safe field policy, durable source-event provenance, deduplication and idempotency, rate and abuse controls, and an outbox or delivery contract.
Never infer a notification:write user scope. A future publisher may create a signal only after the owning domain event is durably committed, and the signal still grants no domain authority.

UPGRADING FROM V1

Legacy calls replaced by this operation

If you maintain an older integration, use this map to find the V2 replacement. Do not translate the old request field-for-field: rebuild it from the V2 parameters and schemas above because identity, authorization, replay protection, and response semantics may have changed.

POST/api/v1/notifications/pushNOTIFICATIONS: Push New Notification

DOCUMENTATION STATUS

This planned contract now defines its public parameters, authorization boundary, replay behavior, responses, and authoritative owner. It remains non-executable until its owner adapter and conformance tests are promoted into the Rust gateway.

Return to the V2 directory ↗