WebSocket Integration
IBEX FI API WebSocket Integration Guide
Overview
The IBEX FI API provides WebSockets to receive real-time updates for your balances and transactions. Data is synchronized with the blockchain through our BCReader infrastructure. The system uses a hybrid architecture that combines real-time WebSocket connections with reliable HTTP fallback endpoints, ensuring your application can always access wallet data.
Benefits of IBEX FI WebSockets
- ✅ Real-time: Instant updates as soon as transactions are mined
- ✅ Automatic: Subscriptions handled automatically by your Safe address
- ✅ Initial data: Balance and transactions sent automatically after authentication
- ✅ Secure: Standard JWT authentication
- ✅ Reliable: Automatic reconnection and error handling
- ✅ Efficient: No constant client-side polling
- ✅ Fallback support: HTTP endpoints available when WebSocket is unavailable
Architecture
Hybrid Architecture
WebSocket Connection
Endpoints
Authentication
Authenticate the connection via a JSON message after the WebSocket opens.
Authentication message (client → server):
Important notes:
- The server extracts
rpIdfrom the hostname and verifies that the JWTissmatchesrpId. - On failure, the server sends
auth_errorwith an explicit message (e.g., expired token). - The JWT token must be valid and not expired.
Connection Lifecycle
Received Messages
Successful Authentication and Initial Data
After successful authentication, you will automatically receive the following messages:
auth_success(orconnection_success)user_data(sent early; may be skipped if recently sent via HTTP — 3s dedup window)balance_datatransaction_datachainid_datarecovery_datauser_data(sent again unconditionally after recovery_data)
Important: user_data may be received twice in the initial burst — clients should handle this gracefully (e.g. overwrite previous data). The order of messages 2–7 should not be relied upon for application logic.
Message Types
1. Authentication Success
Alternative format:
2. Initial Balance Data
3. Initial Transaction Data
4. Balance Update
Received when wallet balance changes:
Alternative format:
5. New Transaction
Received when a new transaction is detected:
6. IBAN Status Update
Emitted when the IBAN status changes for a Safe address (e.g. from pending to approved). Triggered by the /system/users/iban webhook. Only sent when the status actually changes.
- previousState: Previous IBAN status (or
"UNKNOWN"if first provisioning). - newState: New IBAN status (e.g.
"approved","pending","rejected"). - Broadcast to clients connected to the matching
safeAddress.
7. KYC Status Update
Emitted when the KYC (KY) status changes for a user. Triggered by the /system/users/ky webhook. Broadcast to all Safe addresses associated with the user. Only sent when the status actually changes.
- previousKyc: Previous KY value (e.g.
"0","1","2", or"UNKNOWN"). - newKyc: New KY value (
"0"= not started,"1"= pending,"2"= verified). - If the user has multiple Safe addresses, a separate message is sent for each one.
8. Chain Data (ChainId)
9. Recovery Status
10. User Data
User profile (signers, safes, KYC status, IBAN availability). The iban field is only present when the IBAN has been provisioned and approved; it contains only the chainId (the actual IBAN/BIC strings are not exposed over WebSocket).
- ky: Raw KYC status value (
"0"= not started,"1"= pending,"2"= verified). - iban: Present only when the IBAN is approved. Contains
chainIdonly — the IBAN/BIC strings are not included. Field is absent when no approved IBAN exists for that Safe.
HTTP Fallback Endpoints
When WebSocket connections fail or are unavailable, use these HTTP endpoints as fallback:
1. Get User Balances
Endpoint: GET /v1.2/users/me/balances
Headers:
Response:
2. Get User Transactions
Endpoint: GET /v1.2/users/me/transactions
Headers:
Query Parameters (optional):
limit: Number of transactions to returnoffset: Number of transactions to skip
Response:
3. Direct BCReader Proxy
Endpoint: GET /v1.2/bcreader/\{verb\}
Headers:
Examples:
GET /v1.2/bcreader/balancesGET /v1.2/bcreader/transactions?address=0x...
Implementation Examples
JavaScript Vanilla
React Hook
Vue.js Composition API
Error Handling
WebSocket Error Codes
| Code | Reason | Action |
|---|---|---|
| 1008 | Invalid JWT token | Refresh the token and reconnect |
| 1011 | Server error | Wait and reconnect |
| 1006 | Abnormal closure | Reconnect automatically |
HTTP API Errors
| Code | Description | Solution |
|---|---|---|
| 401 | Unauthorized | Refresh JWT token |
| 403 | Forbidden | Check user permissions |
| 404 | Not found | Verify endpoint URL and user data |
| 500 | Internal server error | Retry with exponential backoff |
Handling Expired Tokens
Fallback to HTTP
Best Practices
1. Authentication
2. Connection Management
- Implement exponential backoff for reconnection attempts
- Set maximum reconnection limits to avoid infinite loops
- Use connection heartbeat/ping to detect disconnections early
3. Resource Cleanup
4. Error Handling
- Always implement HTTP fallback when WebSocket fails
- Handle different error codes appropriately (401, 403, 500, etc.)
- Gracefully degrade functionality when services are unavailable
5. Performance Optimization
- Buffer messages during disconnection and sync when reconnected
- Implement message deduplication to handle potential duplicates
- Use efficient JSON parsing for high-frequency updates
6. Security
- Validate JWT tokens before connection attempts
- Handle token expiration gracefully with refresh logic
- Use secure WebSocket connections (wss://) in production
7. Data Management
- Cache recent data to improve user experience during reconnections
- Implement optimistic updates for better perceived performance
- Handle data consistency between WebSocket and HTTP responses
Keep-alive (Ping/Pong)
- The server automatically sends a ping every 30 seconds.
- Standard WebSocket clients automatically respond with a pong — no client action is required.
- On closure, reconnect with exponential backoff.
Rate Limiting
- WebSocket connections: 1 connection per user
- HTTP API calls: 100 requests per minute per user
- Burst allowance: 20 requests in 10 seconds
Debugging
Useful Logs
Connection Check
Support
For any questions or issues:
- 📧 Email: support@ibex.fi
- 📖 Documentation: docs.ibex.fi
- 🐛 Issues: Use your project's ticketing system
Changelog
v1.1.0 (April 2026)
- Fixed
user_datapayload:ibanfield contains only{ chainId }when approved (IBAN/BIC strings are not exposed) - Fixed
kyfield: uses raw values ("0","1","2") not human-readable strings - Documented
user.iban.updatedanduser.ky.updatedpush events with full payload and field descriptions - Corrected initial message sequence:
user_datais sent beforebalance_dataand may be received twice - Added
user.iban.updatedanduser.ky.updatedto all code examples (JS, React, Vue)
v1.0.0 (2024-01-31)
- ✅ WebSocket connection with JWT authentication
- ✅ Real-time balance updates
- ✅ New transaction notifications
- ✅ Automatic reconnection
- ✅ Multi-Safe per user support
- ✅ HTTP fallback endpoints
- ✅ IBAN and KYC status updates
Last Updated: April 2026
Version: 1.1