Organizações, aplicações e ambientes

Uma organização guarda a sua equipe e o faturamento; as aplicações guardam fluxos de trabalho e chaves de API, e cada uma é de produção ou sandbox. Acertar essa estrutura evita a maioria dos comportamentos confusos.

Escrito pelo suporte da Didit · Atualizado em 15 de setembro de 2026

#Os dois níveis

Organização é a sua conta. Ela é dona de:

• Sua equipe e as funções de cada um
• Seu saldo de faturamento e suas faturas
• Seu registro de auditoria
• Todas as suas aplicações

Aplicação é um espaço de trabalho dentro da organização. Ela é dona de:

• Seus próprios fluxos de trabalho
• Sua própria chave de API
• Seus próprios destinos de webhook
• Sua própria política de retenção de dados
• Um modo: live ou sandbox

Troque entre aplicações pelo menu suspenso no topo do console.

#Por que isso importa mais do que parece

Quase todo relato de "eu mudei isso e nada aconteceu" se resolve nessa estrutura:

• Você editou um fluxo de trabalho na aplicação A enquanto suas sessões rodam na aplicação B.
• Você adicionou um destino de webhook a uma aplicação e esperava eventos de outra.
• Você está chamando com uma chave de uma aplicação diferente do recurso que está acessando, e recebendo um 404 ou 403 para algo que claramente existe.

Antes de depurar qualquer outra coisa, confirme a aplicação. Veja erros da API e o que significam.

#Produção e sandbox são aplicações separadas

Não existe um botão de modo de teste dentro de uma aplicação de produção. O modo é escolhido por aplicação, então testar significa criar uma segunda aplicação em modo sandbox e usar a chave dela.

Essa separação é o objetivo: o tráfego de teste e os dados de produção nunca se misturam, e uma chave de sandbox não pode gastar créditos reais por acidente. Veja testando em sandbox.

#Quantas aplicações você deveria ter?

No mínimo, uma de produção e uma sandbox. Além disso, divida por qualquer coisa que precise da sua própria configuração ou do seu próprio isolamento:

• Por produto, quando produtos diferentes precisam de fluxos de trabalho e endpoints de webhook diferentes.
• Por ambiente, se você roda mais de um ambiente de pré-produção.
• Por marca, se você presta verificação sob várias marcas com estilos diferentes.
• Por política de retenção, já que a retenção é configurada por aplicação.

O que não se divide por aplicação: o seu saldo, que é no nível da organização. Toda aplicação consome os mesmos créditos.

#Criando aplicações adicionais

Aplicações adicionais são criadas no console. Se a opção estiver ausente, ou se você precisar criar uma pela API em vez do console, isso é uma questão de permissão no nível da conta que vale a pena perguntar ao suporte em vez de contornar - especialmente para uma segunda aplicação de produção, onde a resposta pode depender do seu plano.

#Várias organizações

O e-mail de uma pessoa pertence a uma organização por vez, e não há como criar suborganizações ou subcontas sob a sua. Se você atende vários clientes próprios, a estrutura suportada é uma aplicação por cliente dentro da sua única organização: cada aplicação tem seus próprios fluxos, marca, chaves de API, resultados e relatórios de uso, totalmente isolados dos demais, enquanto a cobrança fica no nível da organização.

#Revender a Didit

Se você quer embutir a Didit no seu próprio produto e cobrar dos seus clientes por isso, esse é o modelo de revenda. Como funciona, nos termos que o suporte dá a todo mundo que pergunta:

• Crédito pré-pago. Uma compra inicial mínima de US$ 5.000, pré-paga, num acordo de um ano. O crédito nunca expira, fica no nível da sua organização e é consumido por todos os clientes finais que você trouxer, e traz um desconto por volume que cresce com o valor.
• O painel é você quem constrói. Você integra a API da Didit no seu próprio front-end e seus clientes gerenciam ali seus fluxos, marca e papéis. A Didit não fornece uma cópia white label do Business Console; as telas de verificação que seus usuários finais veem podem levar sua marca (veja white label), o console não.
• Sua margem é sua. Você define o preço que seus clientes pagam. A Didit cobra de você por recurso concluído aos preços unitários fixados pelo prazo do acordo.
• Não é um programa de parceiros locais. A Didit faz demonstrações, onboarding e suporte diretamente com os clientes e não busca parceiros de distribuição ou implementação.

Se preferir não cuidar da revenda, use a opção de indicação: na barra lateral do Business Console, abra Indicações, aceite os termos do programa e compartilhe seu link. Você ganha 10% de comissão sobre cada depósito em dinheiro que uma organização indicada fizer, por 36 meses a partir do primeiro depósito dela, utilizável como crédito Didit ou pago por transferência bancária após o período de maturação, sem obrigações de entrega ou suporte. Você pode construir e testar sua integração no plano gratuito antes de se comprometer com qualquer um dos dois.

#Excluindo uma aplicação

Excluir uma aplicação remove seus fluxos de trabalho e configurações. Os dados de verificação dela seguem a política de retenção e as regras de exclusão daqueles dados, não o ciclo de vida da aplicação - então, se o seu objetivo é apagar dados de clientes, exclua os dados explicitamente em vez de presumir que remover a aplicação faz isso. Veja excluindo sessões e dados pessoais.

#Tudo é atribuível

Toda chamada de API registra a qual aplicação ela pertencia, no registro de auditoria, por 365 dias. É isso que torna uma estrutura com várias aplicações auditável, e não apenas organizada. Veja como usar os registros de auditoria.