Primeros pasos
Flujo de integración
Camino correcto de una integración por iframe. El callback se envía antes de avisar al frontend.
sequenceDiagram participant Usuario participant Web participant Widget as Wealth Reader Widget participant API as Wealth Reader API participant Banco as Entidad Financiera Usuario->>Web: Abre la aplicación Web->>Widget: Carga el iframe con operation_id Usuario->>Widget: Elige entidad y da consentimiento Widget->>API: Solicita los datos con operation_id API->>Banco: Consulta Banco-->>API: Responde API-->>Widget: Devuelve datos normalizados Widget->>Web: POST al callback (operation_id + token + payload) Web-->>Widget: HTTP 200 y status ok Widget-->>Web: postMessage flow completed Web-->>Usuario: Muestra finalización OK
Quién hace qué
| Actor | Responsabilidad |
|---|---|
| Tu frontend | Genera un operation_id único, carga el widget y escucha postMessage. |
| El widget | Muestra bancos, login, 2FA y errores al usuario. |
| La API de Wealth Reader | Habla con la entidad y normaliza la respuesta. |
| Tu backend | Expone la URL de callback, responde {"status":"ok"} y guarda operation_id, token y payload. |
Si algo falla
- Password incorrecto, 2FA o un error de la entidad: el widget lo resuelve con el usuario. Tu front puede recibir un JSON de error por
postMessage; el callback no se llama hasta que la lectura termina bien. - Tu callback no responde
200+{"status":"ok"}: el usuario no ve éxito y el front no recibeflow completed. - Un
tokendeja de valer (cambio de contraseña, nuevo 2FA): vuelve a abrir el widget pasando esetokenpara que el usuario se reautentique.
El detalle de cada mensaje y del cuerpo del callback está en las páginas de iframe.
Siguiente paso
Si integras por iframe, sigue por frontend y después backend. Si no puedes embeber un iframe, ve a OAuth.
Última actualización