Organizations, applications and environments

An organization holds your team and billing; applications hold workflows and API keys, and each one is either live or sandbox. Getting this structure right prevents most confusing behaviour.

Written by Didit Support · Updated 19 August 2026

#The two levels

Organization is your account. It owns:

• Your team and their roles
• Your billing balance and invoices
• Your audit log
• All your applications

Application is a workspace inside the organization. It owns:

• Its own workflows
• Its own API key
• Its own webhook destinations
• Its own data-retention policy
• A mode: live or sandbox

Switch between applications from the dropdown at the top of the console.

#Why this matters more than it looks

Almost every "I changed it and nothing happened" report resolves to this structure:

• You edited a workflow in application A while your sessions run under application B.
• You added a webhook destination to one application and expected events from another.
• You're calling with a key from a different application than the resource you're addressing, and getting a 404 or 403 for something that clearly exists.

Before debugging anything else, confirm the application. See API errors and what they mean.

#Live and sandbox are separate applications

There is no test-mode switch inside a live application. The mode is chosen per application, so testing means creating a second application in sandbox mode and using its key.

That separation is the point: test traffic and production data never mix, and a sandbox key can't accidentally spend real credits. See testing in sandbox.

#How many applications should you have?

At minimum, one live and one sandbox. Beyond that, split by anything that needs its own configuration or its own isolation:

• Per product, when different products need different workflows and different webhook endpoints.
• Per environment, if you run more than one pre-production environment.
• Per brand, if you serve verification under several brands with different styling.
• Per retention policy, since retention is configured per application.

What doesn't split per application: your balance, which is organization-level. Every application draws on the same credits.

#Creating additional applications

Additional applications are created in the console. If the option is missing, or you need to create one through the API rather than the console, that's an account-level permission question worth asking support about rather than working around - especially for a second live application, where the answer may involve your plan.

#Multiple organizations

One person's email belongs to one organization at a time. Being part of two organizations - which is what a reseller or agency typically needs - is a different account structure and is not the default. If that's your model, raise it with your Didit contact before you start creating accounts, because untangling several organizations that should have been one is considerably more work than setting it up correctly.

#Deleting an application

Deleting an application removes its workflows and configuration. Its verification data follows the retention policy and deletion rules for that data, not the application's lifecycle - so if your goal is to erase customer data, delete the data explicitly rather than assuming removing the application does it. See deleting sessions and personal data.

#Everything is attributable

Every API call records which application it belonged to, in the audit log, for 365 days. That's what makes a multi-application structure auditable rather than just tidy. See using audit logs.