> ## 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 escopo - Acesso restrito à API de KYC > Didit: cada serviço ou parceiro com sua chave de API: leitura/escrita por recurso, limite de fluxos, lista de IPs, validade e revogação imediata. Prompt de chaves de API com escopo 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 Toda aplicação começa com um **segredo principal** que tem acesso total a tudo o que a aplicação pode fazer. Você pode adicionar **chaves de API nomeadas** ao lado dele, uma por serviço ou parceiro, cada uma com apenas o acesso de que precisa. Dê ao seu provedor de pagamentos uma chave que lê as sessões aprovadas de um fluxo e não pode alterar nada, mantenha uma chave separada para o seu backend e revogue qualquer uma delas sem afetar a outra.> [!NOTE] > > As chaves criadas antes da existência do acesso com escopo mantêm acesso total. > Nada muda para elas até que você edite o acesso delas.***## Onde encontrá-lasNo [**Business Console**](https://business.didit.me), selecione sua aplicação e abra **Developers -> API keys**.A lista mostra todas as chaves da aplicação com o status, as requisições dos últimos 30 dias, quem a criou, o acesso e quando foi usada pela última vez. Clique em uma chave para pré-visualizá-la à direita ou abra a página completa dela para ver o uso, o acesso, as requisições recentes, um snippet de início rápido e a atividade.As chaves pertencem a uma aplicação e funcionam somente para ela. Uma chave usa o ambiente da aplicação: as chaves de uma aplicação de 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 que você selecionou.| Lista | O que ela controla | | - | - | | **URLs de redirecionamento** | Para onde a Didit envia o navegador quando uma verificação hospedada termina. A URL deve corresponder exatamente, incluindo o caminho. | | **Domínios permitidos** | As origens (esquema, host e porta opcional, como `https://app.example.com`) nas quais o fluxo de verificação hospedado pode ser incorporado e para as quais pode redirecionar o usuário. |Quando a lista de **Domínios permitidos** tem entradas, [Create session](https://docs.didit.me/pt-br/sessions-api/create-session.md) rejeita com um erro `400` um `callback` que não esteja em nenhuma delas. Uma lista vazia significa que não há restrições. As chamadas de servidor para servidor não são afetadas.***## Criar uma chave**1. Detalhes**Dê à chave o nome do serviço que vai usá-la e escolha quando ela expira: nunca, em 30 dias, 90 dias, um ano ou em uma data que você escolher. Uma chave expirada para de funcionar no fim desse dia, em UTC.**2. Acesso**Comece por uma predefinição e depois ajuste-a para cada recurso. A chave nunca poderá fazer mais do que isso.**3. Revisão**O console detalha o que a chave pode e o que não pode fazer antes de você entregá-la.**4. Chave secreta**Copie o segredo e guarde-o no seu gerenciador de segredos. Esta é a única vez em que o segredo completo é exibido. Se você perdê-lo, faça a rotação da chave para obter um novo.### Predefinições| Predefinição | Acesso | | - | - | | **Acesso total** | Todos os recursos, com leitura e escrita, incluindo outras chaves de API. Para o seu próprio backend. | | **Somente leitura** | Sessões e decisões, com mídia opcional. Não pode criar, alterar nem excluir nada. Para um parceiro que precisa dos resultados. | | **Personalizado** | Você escolhe Nenhum, Leitura ou Escrita para cada recurso. |### RecursosLeitura abrange requisições `GET` em um recurso; escrita também abrange `POST`, `PUT`, `PATCH` e `DELETE`.| Recurso | Leitura | Escrita | | - | - | - | | **Sessões** | Listar e abrir sessões | Criar, atualizar e excluir sessões, importar sessões e executar verificações avulsas (correspondência facial, verificação de identidade, análise AML e as demais APIs avulsas) | | **Decisões** | Resultados, pontuações de risco, dados extraídos e histórico de análise AML | Aprovar, recusar ou enviar para revisão, e alterar os status dos recursos e dos resultados AML | | **Mídia** | Imagens de documentos, selfies, vídeos e relatórios em PDF | - | | **Pessoas** (`users`) | Usuários finais e tudo o que foi verificado sobre eles | Criar, atualizar e excluir usuários e o monitoramento deles. Criar um usuário com link de verificação também exige escrita em **Sessões** | | **Empresas** (`businesses`) | Perfis de empresas, seus documentos e proprietários | Criar, atualizar e excluir empresas e o monitoramento delas | | **Transações** | Transações, alertas, regras, eventos de monitoramento, dados de Travel Rule e triagem de carteiras | Enviar transações e eventos, alterar seu status e gerenciar as configurações de Travel Rule, o catálogo de endereços de carteiras e as transferências | | **Fluxos de trabalho** | Fluxos, questionários, listas e listas de bloqueio | Criá-los e editá-los | | **Webhooks** | Endpoints e entregas (com leitura em **Decisões**, já que uma entrega contém o payload da sessão que ela enviou) | Adicionar, editar e excluir endpoints, e reenviar entregas | | **Configurações da aplicação** (`applications`) | Personalização e saldo | Alterar a personalização e recarregar o saldo | | **Análises** | Métricas e exportações de relatórios | - | | **Chaves de API** | Reservado para o gerenciamento de chaves | Reservado para o gerenciamento de chaves |Uma chave com acesso personalizado funciona na API pública: nos endpoints de sessões, usuários, empresas, transações, fluxos e webhooks, e nas verificações avulsas. Os endpoints usados apenas pelo Business Console respondem `403` a ela; eles exigem uma chave com acesso total.Uma chave sem leitura em **Mídia** recebe as decisões das sessões com todas as URLs de imagens, vídeos e PDFs definidas como `null`, e os endpoints de relatórios em PDF respondem `403`. Uma chave sem escrita em **Sessões** nunca recebe o link de verificação nem o token de sessão de uma sessão, já que quem os tiver pode concluir a verificação como o usuário final: esses campos retornam como `null`. Pelo mesmo motivo, criar uma pessoa com `send_verification_link: true` exige escrita em **Sessões** além da escrita em **Pessoas**, porque isso cria uma sessão e envia o link dela por e-mail. Sem isso, a chamada responde `403` e não cria nada.### Limites| Limite | O que faz | | - | - | | **Fluxos de trabalho** | A chave só vê as sessões dos fluxos que você escolher e só pode criar sessões com eles. Qualquer outra sessão responde `404`, como se não existisse. | | **Somente sessões aprovadas** | Sessões recusadas, em revisão 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 você listar (até 20, IPv4 ou IPv6). Requisições de qualquer outro endereço respondem `403`. | | **Expira** | Após essa data, toda requisição com a chave responde `401`. |Uma chave limitada a alguns fluxos ou a sessões aprovadas funciona nos endpoints de sessões, onde o limite pode ser aplicado. Ela não pode ter acesso a pessoas, empresas, transações ou análises, e não pode executar verificações avulsas.***## Respostas da API para uma chave com escopo| Status | Significado | | - | - | | **401** | A chave está ausente, incorreta, revogada ou expirada. | | **403** | A chave não tem acesso a esse recurso ou ação, ou a requisição veio de um endereço fora da sua lista de IPs. | | **404** | A sessão está fora dos fluxos ou status da chave. |As listas de sessões retornam apenas as sessões permitidas pelos limites da chave.***## Editar acessoAbra o menu de uma chave, sua visualização ou sua página e escolha **Editar acesso**. Altere a predefinição, os recursos, os limites ou a expiração e depois revise apenas o que muda, antes e depois. O segredo continua o mesmo, então não é preciso fazer nova implantação nada, e o novo acesso entra em vigor em até um minuto.O segredo principal sempre tem acesso total e não pode ser editado.***## Fazer a rotação de uma chaveA rotação substitui o segredo de uma chave. O novo segredo é exibido uma vez, e o segredo atual continua funcionando por **24 horas** para que você possa implantar o novo sem tempo de inatividade. Depois disso, toda requisição com o segredo antigo responde `401`.A rotação do segredo principal é feita da mesma forma, com a mesma sobreposição de 24 horas.***## Revogar uma chaveA revogação desativa uma chave imediatamente: toda requisição feita com ela recebe uma resposta `401`. Isso não pode ser desfeito. O segredo principal não pode ser revogado; faça a rotação dele.***## Uso e trilha de auditoriaCada chave mostra suas requisições nos últimos 30 dias, sua taxa de erros e latência, e suas requisições mais recentes com os códigos de status, incluindo as recusadas devido aos limites da chave.Toda chamada feita com uma chave de API aparece nos [registros de auditoria](https://docs.didit.me/pt-br/console/audit-logs.md) da organização, com o nome da chave que a fez.***## Quem pode gerenciar chavesGerenciar chaves de API exige a permissão **Chaves de API**: leitura para visualizá-las, escrita para criá-las, editá-las, rotacioná-las e revogá-las. Consulte [Funções e permissões](https://docs.didit.me/pt-br/console/roles-permissions.md). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.