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 15 September 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, and there is no way to create sub-organizations or sub-accounts under yours. If you serve several of your own customers, the supported structure is one application per customer inside your single organization: each application has its own workflows, branding, API keys, results and usage reporting, fully isolated from the others, while billing stays at your organization level.

#Reselling Didit

If you want to bundle Didit into your own product and charge your customers for it, that is the reseller model. How it works, in the terms support gives everyone who asks:

• Prepaid credit. A minimum initial purchase of $5,000 USD, prepaid, on a one-year agreement. The credit never expires, it sits at your organization level and is drawn down across all the end customers you bring on, and it carries a volume discount that deepens with the amount.
• You build the dashboard. You integrate Didit's API into your own front end and your customers manage their workflows, branding and roles there. Didit does not provide a white-labelled copy of the Business Console; the verification screens your end users see can carry your brand (see white label), the console cannot.
• Your margin is yours. You set the price your customers pay. Didit bills you per completed feature at the unit prices fixed for the term of the agreement.
• Not a local-partner programme. Didit runs demos, onboarding and support directly with customers and is not looking for distribution or implementation partners.

If you'd rather not handle the resale, use the referral option instead: in the Business Console sidebar, open Referrals, accept the program terms and share your link. You earn a 10% commission on every cash deposit a referred organization makes, for 36 months from their first deposit, usable as Didit credit or paid out by bank transfer once it matures - with no delivery or support obligations. You can build and test your integration on the free tier before committing to either.

#Deleting an application

There is no self-serve way to delete an application today - including a sandbox one - so don't hunt the console for a delete button that isn't there. Your options:

• Stop using it. Rename it (something like acme-old) so nobody picks it by mistake, and revoke its API keys.
• Erase its customer data. Verification data follows the retention policy and deletion rules for that data, not the application's lifecycle - delete the data explicitly. See deleting sessions and personal data.
• Start over. Support can delete the entire organization so you can create a fresh one - a last resort, since it takes the team, balance and history with it.

#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.