Respostas curtas e honestas sobre as suas chaves, os seus bancos e a sua fatura — incluindo as partes menos convenientes do que gostaríamos.
Sim — mas funciona de forma diferente de uma chave de API, e é destrutivo de propósito.
Uma chave de API é uma credencial que guardamos nós, por isso podemos emitir uma nova e revogar a antiga num segundo. A sua chave de cifra não é assim. A metade privada é gerada dentro do seu navegador e nunca chega até nós; só temos a metade pública, suficiente para cifrar dados para si e nunca para os ler. Do nosso lado não há nada para reemitir.
Trocá-la significa, portanto, substituir o par inteiro. Tudo o que já está guardado sob a chave pública antiga fica selado com uma chave privada que deixou de existir — de forma permanente e em todos os dispositivos —, pelo que terá de ligar os bancos outra vez e puxar o histórico do zero. Por precaução, a troca revoga no mesmo instante todas as chaves de API da sua conta.
O fluxo está no ecrã «Este dispositivo não tem a sua chave», em «Não tem a sua chave? Repor e começar de novo». Para lá chegar de propósito: termine sessão, limpe o armazenamento deste site no navegador (ou abra um perfil novo), volte a entrar e escolha «Repor e substituir a minha chave». Se preferir a nossa API: gere um novo par P-256 e envie a nova chave pública em PUT para /api/keys/me — as consequências são idênticas.
Se preferir não fazer isto sozinho, escreva para [email protected] e percorremos os passos consigo.
Não a conseguimos recuperar, e é precisamente esse o objetivo do desenho. A sua frase de acesso nunca sai do seu dispositivo: envolve a chave privada guardada no navegador, e nós não vemos nenhuma das duas.
Se a chave ainda existir num dispositivo a que tenha acesso, desbloqueie-a aí e exporte-a a partir da página de programadores; depois importe o ficheiro no dispositivo de onde está excluído. Se tiver desaparecido em todo o lado, os dados cifrados com ela ficam ilegíveis para sempre e o único caminho é substituir a chave e sincronizar os bancos de novo.
Inicie sessão no dispositivo novo e ele dirá que não tem a sua chave. Num dispositivo que já funciona, abra a página de programadores e exporte o ficheiro da chave. Cole ou carregue esse ficheiro no dispositivo novo e escolha aí uma frase de acesso — cada dispositivo envolve a mesma chave com a sua própria frase.
A importação é verificada contra a chave pública da sua conta, por isso o ficheiro errado é rejeitado logo, em vez de deixar o dispositivo em silêncio, incapaz de ler o que quer que seja.
Não. Tudo o que guardamos por si é selado com a sua chave pública antes de ser escrito, e só a chave privada no seu navegador o volta a abrir. As suas credenciais bancárias nunca nos tocam: autentica-se no site do seu próprio banco.
O que vemos são os dados ao nível da conta necessários para operar o serviço: o seu email, o estado de faturação e quando correu uma sincronização. A arquitetura completa está na página de segurança.
Não — e isso decorre da cifra, não é um limite que tenhamos escolhido. O identificador de que precisamos para falar com o seu banco está ele próprio selado sob a sua chave, por isso uma sincronização só pode arrancar onde essa chave existe: no seu navegador com sessão iniciada, no seu próprio cliente de API ou na CLI.
Abrir a aplicação sincroniza automaticamente, na página de contas pode sincronizar quando quiser, e com a API e os SDK conduz tudo por si.
A DSP2 impõe um prazo ao consentimento que dá ao seu banco, e a maioria dos bancos fixa-o em 90 dias. Quando expira deixamos de poder buscar novidades até voltar a autorizar junto do banco. Avisamos por email antes de acontecer e mostramos um aviso na aplicação.
Voltar a ligar mantém tudo o que já foi sincronizado — nunca recomeça do zero.
Na primeira sincronização pedimos cerca de dois anos e negociamos para baixo se o banco recusar, com um mínimo de 90 dias — o que a DSP2 garante. O que recebe de facto é decisão do banco: uns entregam vários anos, outros ficam-se pelos 90 dias. As regras de consentimento de cada banco estão na página de bancos suportados.
A partir daí, cada sincronização é incremental e aditiva. Nunca apagamos movimentos que já tenhamos guardado por si.
Sim. Um consentimento bancário costuma cobrir mais contas do que realmente quer. Na página de contas pode remover em definitivo as que não precisa, e deixam de contar na fatura a partir do mês seguinte.
Remover uma conta apaga também os dados importados para ela, e não é reversível.
3 € por mês cobrem a sua primeira conta ligada, mais 1 € por mês por cada conta adicional, IVA incluído. As taxas são retiradas de um pequeno saldo pré-pago e os meses parciais são calculados proporcionalmente, por isso nunca paga adiantado por contas que não tem.
Só paga por contas com ligação bancária ativa. O cálculo proporcional, o pagamento automático e a almofada de saldo reembolsável estão explicados em como funciona a faturação.
A mensalidade vai a zero e os dados que já tem continuam visíveis gratuitamente.
O saldo não usado continua a ser o seu dinheiro: escreva para [email protected] e devolvemo-lo sem custos. Se quiser também eliminar os dados, veja apagar a sua conta.
Crie uma chave nova na página de programadores, passe a sua integração para ela e revogue depois a antiga. Uma chave é mostrada apenas uma vez, no momento da criação, por isso guarde-a logo.
Repare que substituir a chave de cifra revoga todas as chaves de API de uma vez — se acabou de o fazer, conte com criar novas. Os clientes que as consomem estão no GitHub.
Nas definições existe uma zona de perigo que apaga permanentemente tudo: ligações bancárias, contas, movimentos, saldos, chaves de API e a chave pública que guardamos por si. Confirma escrevendo o seu endereço de email. À saída, o seu navegador fecha ainda cada consentimento no próprio banco, e a chave guardada localmente é destruída.
É irreversível e depois não há qualquer exportação — faça primeiro a exportação em CSV ou PDF se quiser guardar alguma coisa.
Escreva para [email protected]. Há uma pessoa a ler, e as perguntas que aparecem duas vezes acabam nesta página.