> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Chaves de API com âmbito limitado - Acesso restrito à API KYC > Com a Didit, crie uma chave de API por serviço ou parceiro, com acesso mínimo por recurso, validade, filtro por IP e revogação imediata. Prompt para chaves de API com acesso limitado Copiar o prompt para a área de transferência \

\````# Goal - call Didit with a scoped API key

Every application has a primary secret with full access, and any number of named API keys.
A named key carries its own access: read or write per resource, optional limits, an optional IP allowlist and an optional expiry date.
Keys are created, edited, rotated and revoked in the Business Console (Developers -> API keys); there is no API to manage them.

\## Sending the key

\```bash
curl https://verification.didit.me/v3/session/$SESSION_ID/decision/ \
-H "x-api-key: $DIDIT_API_KEY"
\```

Read the key from an environment variable or a secrets manager, never from source code.

\## What each answer means

\| Status | Meaning |
\|---|---|
\| 401 | The key is missing, wrong, revoked or expired |
\| 403 | The key has no access to this resource or action, or the request came from an address outside its IP list |
\| 404 | The session is outside the key's workflows or statuses, so to this key it does not exist |

A key without media access receives decisions with every image, video and PDF URL set to null, and gets 403 on PDF reports.
A key without sessions write receives session_url and session_token as null.

\## Resources

sessions, decisions, media (read only), users, businesses, transactions, workflows, webhooks, applications, analytics (read only), api-keys.
Read covers GET requests, write covers POST, PUT, PATCH and DELETE.
Standalone checks (face match, ID verification, AML screening and the other /v3 standalone APIs) need sessions write.
Creating a person with send_verification_link: true (POST /v3/users/create/) needs users write and sessions write; without sessions write it answers 403 and nothing is created.

\## Limits

\- workflow_ids: only sessions of these workflows are visible, and sessions can only be created with them.
\- approved sessions only: declined, in-review and unfinished sessions are hidden.
\- A key with either limit cannot have access to users, businesses, transactions or analytics.

\## Rotation

Rotating a key returns a new secret once; the previous secret keeps working for 24 hours.````

\
Colar em Cada aplicação começa com um **segredo principal** que tem acesso total a tudo o que a aplicação pode fazer. Pode adicionar **chaves de API nomeadas** junto a ele, uma por serviço ou parceiro, cada uma apenas com o acesso de que precisa. Dê ao seu fornecedor de pagamentos uma chave que lê as sessões aprovadas de um único fluxo e não consegue alterar nada, mantenha uma chave separada para o seu backend, e revogue qualquer uma delas sem afetar a outra.> [!NOTE] > > As chaves criadas antes do acesso limitado continuam a ter acesso total. > Nada muda para elas até que edite o respetivo acesso.***## Onde encontrar as chavesNa [**Consola Empresarial**](https://business.didit.me), selecione a sua aplicação e abra **Developers -> API keys**.A lista mostra todas as chaves da aplicação, com o respetivo estado, os pedidos dos últimos 30 dias, quem a criou, o respetivo acesso e a data da última utilização. Clique numa chave para a pré-visualizar à direita, ou abra a respetiva página completa para ver a utilização, o acesso, os pedidos recentes, um trecho de início rápido e a atividade.As chaves pertencem a uma única aplicação e funcionam apenas para ela. Uma chave herda o ambiente da aplicação: as chaves de uma aplicação sandbox nunca criam verificações faturadas.***## URLs de redirecionamento e domínios permitidosAbra **Developers > API keys > Redirects and domains** para definir duas listas para a aplicação e o ambiente selecionados.| Lista | O que controla | | - | - | | **URLs de redirecionamento** | Para onde a Didit envia o navegador quando uma verificação alojada termina. Um URL tem de corresponder exatamente, incluindo o caminho. | | **Domínios permitidos** | As origens (esquema, host e porta opcional, como `https://app.example.com`) em que o fluxo de verificação alojado pode ser incorporado e para onde pode devolver o utilizador. |Quando a lista **Domínios permitidos** tem entradas, o [Criar sessão](https://docs.didit.me/pt/sessions-api/create-session.md) rejeita um `callback` que não esteja em nenhuma delas, com um erro `400`. Uma lista vazia significa que não há restrição. As chamadas servidor a servidor não são afetadas.***## Criar uma chave**1. Detalhes**Dê à chave o nome do serviço que a vai usar e escolha quando expira: nunca, em 30 dias, em 90 dias, num ano ou numa data à sua escolha. Uma chave expirada deixa de funcionar no fim desse dia, em UTC.**2. Acesso**Comece por uma predefinição e depois ajuste-a recurso a recurso. A chave nunca pode fazer mais do que isto.**3. Revisão**A consola indica de forma clara o que a chave pode e não pode fazer, antes de a entregar.**4. Chave secreta**Copie o segredo e guarde-o no seu gestor de segredos. Esta é a única vez em que o segredo completo é mostrado. Se o perder, rode a chave para obter um novo.### Predefinições| Predefinição | Acesso | | - | - | | **Acesso total** | Todos os recursos, em leitura e escrita, incluindo outras chaves de API. Para o seu próprio backend. | | **Só de leitura** | Sessões e decisões, com multimédia opcional. Não pode criar, alterar nem eliminar nada. Para um parceiro que precisa dos resultados. | | **Personalizado** | Escolha Nenhum, Leitura ou Escrita para cada recurso. |### RecursosA leitura abrange os pedidos `GET` a um recurso; a escrita abrange também `POST`, `PUT`, `PATCH` e `DELETE`.| Recurso | Leitura | Escrita | | - | - | - | | **Sessões** | Listar e abrir sessões | Criar, atualizar e eliminar sessões, importar sessões e executar verificações autónomas (correspondência facial, verificação de identidade, triagem AML e as restantes APIs autónomas) | | **Decisões** | Resultados, pontuações de risco, dados extraídos e histórico de triagem AML | Aprovar, recusar ou enviar para revisão, e alterar os estados das funcionalidades e das correspondências de AML | | **Multimédia** | Imagens de documentos, selfies, vídeos e relatórios PDF | - | | **Pessoas** (`users`) | Utilizadores finais e tudo o que foi verificado sobre eles | Criar, atualizar e eliminar utilizadores, e a respetiva monitorização. Criar um utilizador com uma ligação de verificação requer também escrita em **Sessões** | | **Empresas** (`businesses`) | Perfis de empresas, respetivos documentos e proprietários | Criar, atualizar e eliminar empresas, e a respetiva monitorização | | **Transações** | Transações, alertas, regras, eventos de monitorização, dados da Travel Rule e triagem de carteiras | Enviar transações e eventos, alterar o respetivo estado, e gerir as definições da Travel Rule, a lista de endereços de carteiras e as transferências | | **Fluxos** | Fluxos, questionários, listas e listas de bloqueio | Criar e editar | | **Webhooks** | Endpoints e entregas (com leitura de **Decisões**, porque uma entrega transporta o payload da sessão que enviou) | Adicionar, editar e eliminar endpoints, e reenviar entregas | | **Definições da aplicação** (`applications`) | Personalização e saldo | Alterar a personalização e carregar saldo | | **Análises** | Métricas e exportações de relatórios | - | | **Chaves de API** | Reservado à gestão de chaves | Reservado à gestão de chaves |Uma chave com acesso personalizado funciona na API pública: nos endpoints de sessão, de utilizador, de empresa, de transação, de fluxo e de webhook, e nas verificações autónomas. Os endpoints que só a Business Console usa respondem `403` a esta chave; exigem uma chave com acesso total.Uma chave sem leitura de **Multimédia** recebe as decisões das sessões com todos os URLs de imagens, vídeos e PDFs definidos como `null`, e os endpoints de relatórios PDF respondem `403`. Uma chave sem escrita em **Sessões** nunca recebe a ligação de verificação nem o token de sessão de uma sessão, uma vez que quem os tiver pode concluir a verificação em nome do utilizador final: esses campos são devolvidos com o valor `null`. Pelo mesmo motivo, criar uma pessoa com `send_verification_link: true` requer escrita em **Sessões** além de escrita em **Pessoas**, porque cria uma sessão e envia a respetiva ligação por e-mail. Sem isso, a chamada responde `403` e não cria nada.### Limites| Limite | O que faz | | - | - | | **Fluxos** | A chave só vê as sessões dos fluxos que escolher, e só pode criar sessões com esses fluxos. Qualquer outra sessão responde `404`, como se não existisse. | | **Apenas sessões aprovadas** | Sessões recusadas, em análise e não concluídas ficam ocultas para a chave. | | **Endereços IP** | A chave só funciona a partir dos endereços ou intervalos CIDR que indicar (até 20, IPv4 ou IPv6). Os pedidos de qualquer outro endereço respondem `403`. | | **Expira** | Após esta data, todos os pedidos com a chave respondem `401`. |Uma chave limitada a alguns fluxos ou a sessões aprovadas funciona nos endpoints de sessões, onde o limite pode ser aplicado. Não pode ter acesso a pessoas, empresas, transações ou análises, e não pode executar verificações autónomas.***## Como a API responde a uma chave com restrições| Estado | Significado | | - | - | | **401** | A chave está em falta, é incorreta, foi revogada ou expirou. | | **403** | A chave não tem acesso a este recurso ou ação, ou o pedido veio de um endereço fora da sua lista de IP. | | **404** | A sessão está fora dos fluxos ou dos estados permitidos pela chave. |As listas de sessões devolvem apenas as sessões que os limites da chave permitem.***## Editar acessoAbra o menu, a pré-visualização ou a página de uma chave e escolha **Edit access**. Altere a predefinição, os recursos, os limites ou a expiração, e depois reveja apenas o que muda, antes e depois. O segredo mantém-se, pelo que não é necessário voltar a implementar nada, e o novo acesso aplica-se no prazo de um minuto.O segredo principal tem sempre acesso total e não pode ser editado.***## Rodar uma chaveRodar substitui o segredo de uma chave. O novo segredo é mostrado uma única vez, e o segredo atual continua a funcionar durante **24 horas**, para que possa implementar o novo sem interrupção do serviço. Passado esse prazo, todos os pedidos feitos com o segredo antigo respondem `401`.O segredo principal é rodado da mesma forma, com a mesma sobreposição de 24 horas.***## Revogar uma chaveA revogação desativa imediatamente uma chave: todos os pedidos feitos com ela respondem `401`. Não pode ser desfeita. O segredo principal não pode ser revogado; em alternativa, rode-o.***## Utilização e registo de auditoriaCada chave mostra os seus pedidos dos últimos 30 dias, a respetiva taxa de erro e latência, e os pedidos mais recentes com os códigos de estado, incluindo os que foram recusados pelos respetivos limites.Cada chamada feita com uma chave de API aparece nos [registos de auditoria](https://docs.didit.me/pt/console/audit-logs.md) da organização, com o nome da chave que fez a chamada.***## Quem pode gerir chavesGerir chaves de API requer a permissão **Chaves de API**: leitura para as ver e escrita para as criar, editar, rodar e revogar. Consulte [Funções e permissões](https://docs.didit.me/pt/console/roles-permissions.md). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.