Skip to main content

Stream notifications (SSE)

GET 
/v2/config/digital-wallet/openid/notifications/sse

Streams wallet notifications for OID4VCI credential lifecycle events over Server-Sent Events. The server keeps the connection open and writes one frame for each new notification.

Authentication​

The browser EventSource API cannot set request headers. The server therefore reads the Authorization header first, and it falls back to the authorization query parameter only when that header is empty. Give the scheme prefix and the space in the value, that is ApiKey <key> or Bearer <token>. The server accepts both schemes on this operation.

Response headers​

Content-Type: text/event-stream, Cache-Control: no-cache, Connection: keep-alive.

Frames that the server writes​

  1. retry: 30000 - the server writes this frame first, before it checks the organisation. It tells the client to wait 30 seconds before it reconnects.
  2. event: connected with the data {} - the server writes this frame after the subscription is live.
  3. event: notification - one frame for each new notification. The frame holds an id field with the stream sequence number, and a data field with the notification object.
  4. : keep-alive - an SSE comment line every 15 seconds. It carries no event, and clients ignore it.
  5. event: error - the server writes this frame when it cannot find the organisation or cannot resolve the wallet, and it then closes the stream. The data holds one field, error. The status line is already sent at that point, so this frame arrives with HTTP 200, not with a 4xx status.

Payload of a notification frame​

The data field holds the notification object with no envelope, unlike the read and update operations, which wrap the object in notification. The object always holds these eight fields: id, organisationId, notificationType, notificationTypeRelatedId, notificationContent, status, createdAt and updatedAt. Note organisationId, which the read, update and list operations do not return. The status of a new notification is always unread, and createdAt and updatedAt are Unix timestamps in seconds.

Behaviour​

The server writes a frame only when it creates a notification. A status change and a deletion produce no frame. The server does not replay frames that the client missed: a reconnection starts from live traffic, and Last-Event-ID is not supported. Use the list operation to read the notifications that the wallet holds already. When a client reads the stream too slowly, the server drops frames for that client rather than blocking the other clients, so the id sequence can hold gaps.

This operation takes no filter parameters. The server ignores status, limit and offset on this path. Use the list operation to filter notifications.

Request​

Query Parameters

    authorization stringrequired

    Authorization value with its scheme prefix, for example ApiKey <key> or Bearer <token>. Use this parameter when the client cannot send the Authorization header, for example the browser EventSource API. The server reads the header first and uses this parameter only when the header is empty.

Header Parameters

    X-SandboxOrgId stringrequired

    Optional. Unique identifier of the sandbox organisation to use for this request. When you send this header, the service runs the operation in the context of the named sandbox organisation, that is, against the wallet of that sandbox organisation and not against the main wallet of the organisation. Leave the header out to use the main wallet.

    The service reads this header only when you authenticate with a bearer access token. When you authenticate with an API key, the service takes the sandbox organisation from the API key and ignores this header. To run an API-key call in a sandbox organisation, bind the key to the sandbox organisation with PUT /v2/config/admin/apikey/{apiKeyId}/sandbox-org instead.

    X-SubwalletId is the deprecated name of this header. The service continues to accept it, but X-SandboxOrgId wins if you send both headers.

    The sandbox organisation must exist, must belong to your organisation and must be deployed. An unknown identifier, an identifier of a sandbox organisation that is not deployed, and an identifier that belongs to a different organisation all make the call fail with HTTP 400.

    Example: 6889e1a4c5b2f30001a3d710

Responses​

The server opened the Server-Sent Events stream. The response stays open until the client closes the connection or the server closes the channel.

Response Headers
  • Cache-Control string

    The server always sends no-cache.

  • Connection string

    The server always sends keep-alive.

Schema

    string

Loading...
Last updated on