The API Registro Pendientes pushes real-time notifications to connected clients using STOMP over WebSocket, with a SockJS fallback for environments where native WebSocket connections are blocked. Each authenticated user subscribes to their own topic and receives typed notification messages as field work order events occur.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/CLINTONARMANDO/apiregistropendientes/llms.txt
Use this file to discover all available pages before exploring further.
Overview
The server uses Spring’s@EnableWebSocketMessageBroker with a simple in-memory broker. The architecture is:
- Transport: WebSocket (native), with SockJS HTTP fallback
- Protocol: STOMP (Simple Text Oriented Messaging Protocol)
- Broker destinations:
/topic/**— server-to-client broadcasts - Application destinations:
/app/**— client-to-server messages
Connection endpoint
| Detail | Value |
|---|---|
| SockJS URL | http://host:8080/ws |
| Native WebSocket | ws://host:8080/ws |
| Allowed origins | * (all origins permitted) |
Always use the SockJS URL (HTTP scheme) when constructing the
SockJS client — the library negotiates the best available transport automatically, including native WebSocket where available.Installing client libraries
- npm
- yarn
- CDN
Connecting and subscribing
Create the STOMP client
Instantiate a
Client with a webSocketFactory that returns a SockJS connection. Pass your JWT in the connectHeaders so the server can identify the user.Subscribe to the user notification topic
Inside the
onConnect callback, subscribe to /topic/usuario/{userId}. Replace userId with the authenticated user’s ID.Activate the client
Call
activate() to open the connection. The client connects, sends the STOMP CONNECT frame with your headers, and fires onConnect when the handshake completes.Full JavaScript example
Notification message structure
Every message published to/topic/usuario/{userId} is a JSON object with the following fields:
| Field | Type | Description |
|---|---|---|
id | number | Unique notification identifier |
titulo | string | Short notification title |
mensaje | string | Full notification body text |
tipo | string | Severity level — see values below |
estado | string | Read state — see values below |
fechaCreacion | string | ISO 8601 timestamp of when the notification was created |
usuarioId | number | ID of the user this notification belongs to |
Example payload
tipo values
| Value | Meaning |
|---|---|
INFO | Informational — no action required |
SUCCESS | A task or operation completed successfully |
WARNING | Something may need attention |
ERROR | An error occurred that requires action |
estado values
| Value | Meaning |
|---|---|
NO_LEIDO | Notification has not been read yet |
LEIDO | Notification has been marked as read |
Authentication
The WebSocket endpoint does not enforce authentication at the transport level, but your backend logic is expected to validate the token passed inconnectHeaders. Two approaches are supported:
- STOMP connect headers (recommended)
- Query parameter
Pass the JWT as an
Authorization header in the STOMP CONNECT frame. This is the preferred approach because the token travels over the encrypted WebSocket frame, not in the URL.Error handling and reconnection
Automatic reconnection
SetreconnectDelay (in milliseconds) to have the client automatically attempt to reconnect after a dropped connection. A value of 5000 retries every 5 seconds:
Handling STOMP errors
UseonStompError to catch protocol-level errors such as authentication failures:
Handling WebSocket close events
Sending messages to the server
To send a STOMP message to the server (e.g., to trigger or acknowledge a notification), publish to the/app/notificacion destination:
The
/app prefix maps to the application destination prefix configured in WebSocketConfig. The server routes messages sent to /app/notificacion through the NotificacionSocketController.