Organizations, applications and environments

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

#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 keys
• Its own webhook endpoints
• Its own data-retention policy
• Its own products, where turning products on per application has rolled out. See products and what they include
• Two environments: Live and Sandbox

Switch application from the application card at the top of the sidebar. Switching applies immediately. The same menu opens Application settings and Create application.

#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 endpoint to one application and expected events from another.
• You're looking at Sandbox while your traffic runs in Live, or the other way round.
• 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 environments

New applications are Live. Testing happens in Sandbox: your organization's shared test application, with its own data and its own keys. Switch between them with the Live and Sandbox pill under the application name in the sidebar.

Verifications, API keys, webhooks and lists are separate in each environment. Branding is shared, and workflows are built once and can be copied between environments. 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?

Most teams start with one, which already gives you Live and 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 pre-production environment, if you need more than the one Sandbox.
• 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

Open the application card at the top of the sidebar and choose Create application, then enter an Application name (where products per application have rolled out, you also choose what it's for). 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.

#Multiple organizations

One person can belong to several organizations, and switches between them from the organization menu at the top of the sidebar, where pending invitations also appear. Creating more than one organization yourself is limited to reseller accounts (contact support to enable it), 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, open Settings → Refer and earn, get your link and share it. 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 plan before committing to either.

#Deleting an application

Permanent deletion of an application isn't available yet: Application settings has a Danger zone, but it says deletion is unavailable and deletes nothing. Your options until then:

• Stop using it. Rename it (something like acme-old) so nobody picks it by mistake, and revoke its API keys under Developers → 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 change records which application it belonged to, in the audit log. That's what makes a multi-application structure auditable rather than just tidy. See using audit logs.