Organitzacions, aplicacions i entorns

Una organització conté el teu equip i la facturació; les aplicacions contenen fluxos de treball i claus API, i cadascuna és live o sandbox. Encertar aquesta estructura evita la majoria de comportaments confusos.

Escrit pel suport de Didit · Actualitzat el 15 de setembre del 2026

#Els dos nivells

Organització és el teu compte. Conté:

• El teu equip i els seus rols
• El teu saldo de facturació i les factures
• El teu registre d'auditoria
• Totes les teves aplicacions

Aplicació és un espai de treball dins de l'organització. Conté:

• Els seus propis fluxos de treball
• La seva pròpia clau API
• Les seves pròpies destinacions de webhook
• La seva pròpia política de retenció de dades
• Un mode: live o sandbox

Canvia entre aplicacions des del desplegable a la part superior de la consola.

#Per què això importa més del que sembla

Gairebé tots els informes de "ho he canviat i no ha passat res" es resolen amb aquesta estructura:

• Has editat un flux de treball a l'aplicació A mentre les teves sessions s'executen a l'aplicació B.
• Has afegit una destinació de webhook a una aplicació i esperaves esdeveniments d'una altra.
• Estàs fent la crida amb una clau d'una aplicació diferent del recurs que estàs adreçant, i reps un 404 o un 403 per alguna cosa que clarament existeix.

Abans de depurar qualsevol altra cosa, confirma l'aplicació. Consulta errors de l'API i què signifiquen.

#Live i sandbox són aplicacions separades

No hi ha cap interruptor de mode de prova dins d'una aplicació live. El mode es tria per aplicació, així que fer proves vol dir crear una segona aplicació en mode sandbox i fer servir la seva clau.

Aquesta separació és precisament l'objectiu: el trànsit de proves i les dades de producció no es barregen mai, i una clau sandbox no pot gastar accidentalment crèdits reals. Consulta provar en sandbox.

#Quantes aplicacions hauries de tenir?

Com a mínim, una live i una sandbox. Més enllà d'això, separa-les per qualsevol cosa que necessiti la seva pròpia configuració o el seu propi aïllament:

• Per producte, quan diferents productes necessiten fluxos de treball i endpoints de webhook diferents.
• Per entorn, si fas servir més d'un entorn de preproducció.
• Per marca, si ofereixes verificació sota diverses marques amb estils diferents.
• Per política de retenció, ja que la retenció es configura per aplicació.

El que no se separa per aplicació és el teu saldo, que és a nivell d'organització. Totes les aplicacions consumeixen els mateixos crèdits.

#Crear aplicacions addicionals

Les aplicacions addicionals es creen a la consola. Si l'opció no hi és, o necessites crear-ne una a través de l'API en lloc de la consola, és una qüestió de permisos a nivell de compte que val la pena preguntar a suport en lloc de buscar-hi una solució alternativa, especialment per a una segona aplicació live, on la resposta pot dependre del teu pla.

#Diverses organitzacions

El correu d'una persona pertany a una sola organització alhora, i no hi ha manera de crear suborganitzacions ni subcomptes sota la teva. Si dones servei a diversos clients propis, l'estructura suportada és una aplicació per client dins de la teva única organització: cada aplicació té els seus propis fluxos, marca, claus d'API, resultats i informes d'ús, totalment aïllats de la resta, mentre la facturació es queda a nivell d'organització.

#Revendre Didit

Si vols integrar Didit al teu propi producte i cobrar-ho als teus clients, això és el model de reseller. Així funciona, en els termes que suport dona a tothom que ho pregunta:

• Crèdit prepagat. Una compra inicial mínima de 5.000 USD, prepagada, amb un acord d'un any. El crèdit no caduca mai, és a nivell de la teva organització i es consumeix entre tots els clients finals que incorporis, i porta un descompte per volum que creix amb l'import.
• El tauler el construeixes tu. Integres l'API de Didit al teu propi front-end i els teus clients hi gestionen els seus fluxos, la seva marca i els seus rols. Didit no ofereix una còpia de marca blanca de la Business Console; les pantalles de verificació que veuen els teus usuaris finals sí que poden portar la teva marca (consulta marca blanca), la consola no.
• El teu marge és teu. Tu fixes el preu que paguen els teus clients. Didit et factura per funció completada als preus unitaris fixats durant la vigència de l'acord.
• No és un programa de partners locals. Didit fa les demos, la incorporació i el suport directament amb els clients i no busca partners de distribució ni d'implementació.

Si prefereixes no gestionar la revenda, fes servir l'opció de referiments: a la barra lateral de la Business Console obre Referiments, accepta els termes del programa i comparteix el teu enllaç. Guanyes una comissió del 10 % sobre cada dipòsit en efectiu que faci una organització referida, durant 36 mesos des del seu primer dipòsit, utilitzable com a crèdit de Didit o cobrable per transferència bancària quan maduri, sense obligacions de lliurament ni de suport. Pots construir i provar la teva integració al pla gratuït abans de comprometre't amb cap de les dues.

#Eliminar una aplicació

Eliminar una aplicació elimina els seus fluxos de treball i configuració. Les seves dades de verificació segueixen la política de retenció i les regles d'eliminació per a aquestes dades, no el cicle de vida de l'aplicació, així que si el teu objectiu és eliminar dades de clients, elimina les dades explícitament en lloc de suposar que eliminar l'aplicació ho fa. Consulta eliminar sessions i dades personals.

#Tot és atribuïble

Cada crida API registra a quina aplicació pertanyia, al registre d'auditoria, durant 365 dies. Això és el que fa que una estructura de diverses aplicacions sigui auditable i no només ordenada. Consulta fer servir els registres d'auditoria.