CorebanqCorebanq Developer Docs
Notificationsv1

NOT IMPLEMENTED — notification preferences (read)

STUB. The handler takes no request at all — its parameter is discarded — and unconditionally answers 200 {"message": "Not implemented"}. No preferences are stored or read anywhere. Do not build against this route; it cannot fail and it cannot return data.

GET
/v1/notifications/preferences

Authorization

BearerAuth
AuthorizationBearer <token>

In: header

Response Body

application/json

application/json

application/json

application/json

application/json

application/json

curl -X GET "https://example.com/v1/notifications/preferences"
{
  "message": "Not implemented"
}
{
  "status": 401,
  "message": "Unauthorized",
  "code": "common.unauthorized",
  "class": "business"
}
{
  "status": 403,
  "message": "No access to the record",
  "code": "common.rbac_no_rec_access",
  "class": "business"
}
{
  "status": 429,
  "message": "Rate limit for 203.0.113.10 to 8f1d2c34-5b6e-4a70-9c81-2d3e4f5a6b7c exceeded.",
  "code": "rate_limits_m.exceeded",
  "class": "temporary",
  "retryable": true
}
{
  "status": 500,
  "message": "Internal server error",
  "code": "common.server_error",
  "class": "business"
}

{
  "overall_status": "unhealthy",
  "message": "Service is shutting down",
  "timestamp": "2026-08-27T15:04:05Z"
}

GETRead one notification

Reads one row scoped to the caller and, when supplied, the customer. title and content are resolved into the request's language before the row is returned — FROM THE KEYS ONLY. Unlike the list, this route never consults the event push template, so a templated notification reads differently here; and link_url and link_text are never populated on this route at all. See the UserNotification schema.

DELDelete one notification

READ THE notification_id NOTE BELOW: this route addresses A DIFFERENT TABLE from every other route in this document. The caller's user id is NOT a scope. It is only written into deleted_by; the lookup is by primary key alone, so any caller the endpoint grant admits can soft-delete any notification whose id they know. customer_id is not read either, unlike the read and mark-read routes. The delete is logical: deleted, deleted_at and deleted_by are set and the row is saved. Answers 200 with a {"message": "Notification deleted"} map, NOT 204 and NOT the StdResponse envelope. The message is a fixed English string with no i18n key.