IframePasso 2 de 2
Configurar o backend
Receba os dados bancários normalizados no seu servidor e confirme corretamente a callback.
Complete o Checklist de frontend. O widget não envia os dados bancários por postMessage- ele os envia para cá, usando POST.
Checklist de integração
0 de 41. Crie a URL callback
Exponha um endpoint HTTPS no seu servidor que aceite POST com um corpo em JSON.
Após processar o que é necessário, responda HTTP 200 com o seguinte JSON:
{
"status": "ok"
}
Se você devolver outro código de status ou outro JSON , o widget não notificará a interface de que o fluxo foi concluído com sucesso.
Trate operation_id como idempotente: Entrega repetida não deve criar duas operações no seu sistema.
2. O que está vindo no POST
O corpo é o mesmo JSON que POST /entities/ no Referência OpenAPI. Os pontos importantes para cruzar a operação:
| Campo | Aplicação |
|---|---|
success |
true se a leitura terminou bem. |
payload |
Dados padronizados (contas, carteiras, cartões, etc.). |
statistics.operation_id |
O operation_id gerado pelo seu frontend. |
statistics.token |
Credencial armazenada para atualizações posteriores (se a tokenização estiver ativa). |
statistics.code |
Código da entidade (bbva, caixabank, ...). |
statistics.SESSION |
ID de sessão, útil em um chamado de suporte. |
statistics.warnings |
Avisos que não invalidam a leitura (por exemplo, um produto vazio). |
Exemplo recortado:
{
"success": true,
"payload": {
"user_information": {
"ID": "12345678Z",
"name": "LUIS GARCIA BAQUERO"
},
"accounts": [
{
"uuid": "8076932f04f73e27fe608fee4d12fca8708dec8c",
"subtype": "checking",
"code": "ES4914651234561234567890",
"name": "Cuenta NOMINA",
"currency": "EUR",
"balances": {
"available": 14302.07,
"current": 14302.07
},
"transactions": []
}
]
},
"statistics": {
"SESSION": "A1B2C3D4E5F67890",
"execution_time": 12.4,
"warnings": [],
"operation_id": "8f1c2a6e-4b0d-4c3a-9e21-0d5b7a91c4e2",
"token": "FRJ0mHlaqZwLzu",
"code": "bbva"
}
}
O esquema completo de payload está na OpenAPI. Não presuma que todas as chaves sempre vêm: elas dependem de product_types e do que o usuário possui na entidade.
3. Domínio associado, callback e chave API
Na área de clientes, associe:
- o domínio de onde o widget é carregado (a origem da sua frente);
- a URL de callback você acabou de criar;
- Seu
api_key.
Até que o domínio seja registrado, o widget não funciona.
4. Teste o fluxo
Abra a página que carrega o widget e faça login:
| Usuário | Senha | Resultado |
|---|---|---|
MOCKDATA |
Qualquer | Leitura bem-sucedida com dados de amostra anonimizados. O callback recebe uma JSON success: true. |
MOCKOTP |
Qualquer | Você recria um desafio de dois fatores. |
MOCKLOGINKO |
Qualquer | Você recria um erro de login. O callback não é chamado. |
Se você não tiver o e-mail de boas-vindas, peça em support@wealthreader.com.
Se quiser ver o POST antes de ter o endpoint no seu ambiente, crie uma URL temporária em um serviço como https://pipedream.com/ e coloque como callback.
5. Atualização de dados (opcional)
Até agora, você tem uma integração one-shot: uma leitura para cada vez que o usuário abre o widget.
Se precisar de um lote noturno ou de um botão de "atualizar", ligue novamente para o API com a token e code que salvou do callback. Não peça um novo nome de usuário e senha.
curl --location 'https://api.wealthreader.com/entities/' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'api_key=TU_API_KEY' \
--data-urlencode 'code=bbva' \
--data-urlencode 'token=EL_TOKEN_DEL_CALLBACK' \
--data-urlencode 'product_types=accounts,portfolios'
Preste atenção na Códigos de Erro: Uma senha inválida não é retentada; uma manutenção de entidade é.
- Especificação OpenAPI v3
- Postman Coleção
Se o token não for mais válido (mudança de senha ou nova 2FA), abra o widget novamente passando esse valor para wr_conf.token para que o usuário possa autenticar novamente.