Organizaciones, aplicaciones y entornos

Una organización contiene tu equipo y tu facturación; las aplicaciones contienen los flujos de trabajo y las claves de API, y cada una es de producción o de sandbox. Tener esta estructura clara evita la mayoría de los comportamientos confusos.

Escrito por el soporte de Didit · Actualizado el 15 de septiembre de 2026

#Los dos niveles

Organización es tu cuenta. Es propietaria de:

• Tu equipo y sus roles
• Tu saldo de facturación y tus facturas
• Tu registro de auditoría
• Todas tus aplicaciones

Aplicación es un espacio de trabajo dentro de la organización. Es propietaria de:

• Sus propios flujos de trabajo
• Su propia clave de API
• Sus propios destinos de webhook
• Su propia política de retención de datos
• Un modo: live o sandbox

Cambia entre aplicaciones desde el desplegable de la parte superior de la consola.

#Por qué esto importa más de lo que parece

Casi todos los reportes de "lo cambié y no pasó nada" se resuelven con esta estructura:

• Editaste un flujo de trabajo en la aplicación A mientras tus sesiones se ejecutan bajo la aplicación B.
• Añadiste un destino de webhook a una aplicación y esperabas eventos de otra.
• Estás llamando con una clave de una aplicación distinta del recurso al que te diriges, y obtienes un 404 o un 403 para algo que claramente existe.

Antes de depurar cualquier otra cosa, confirma la aplicación. Consulta errores de la API y qué significan.

#Producción y sandbox son aplicaciones separadas

No existe un interruptor de modo de prueba dentro de una aplicación de producción. El modo se elige por aplicación, así que probar significa crear una segunda aplicación en modo sandbox y usar su clave.

Esa separación es la clave: el tráfico de prueba y los datos de producción nunca se mezclan, y una clave de sandbox no puede gastar créditos reales por accidente. Consulta pruebas en sandbox.

#¿Cuántas aplicaciones deberías tener?

Como mínimo, una de producción y una de sandbox. Más allá de eso, divide por cualquier cosa que necesite su propia configuración o su propio aislamiento:

• Por producto, cuando productos distintos necesiten flujos de trabajo y endpoints de webhook distintos.
• Por entorno, si ejecutas más de un entorno de preproducción.
• Por marca, si ofreces verificación bajo varias marcas con estilos distintos.
• Por política de retención, ya que la retención se configura por aplicación.

Lo que no se divide por aplicación: tu saldo, que es a nivel de organización. Todas las aplicaciones consumen de los mismos créditos.

#Crear aplicaciones adicionales

Las aplicaciones adicionales se crean en la consola. Si falta la opción, o necesitas crear una a través de la API en lugar de la consola, eso es una cuestión de permisos a nivel de cuenta que conviene preguntar a soporte en lugar de intentar sortear, especialmente para una segunda aplicación de producción, donde la respuesta puede depender de tu plan.

#Varias organizaciones

El correo de una persona pertenece a una sola organización a la vez, y no hay forma de crear suborganizaciones ni subcuentas bajo la tuya. Si das servicio a varios clientes propios, la estructura soportada es una aplicación por cliente dentro de tu única organización: cada aplicación tiene sus propios flujos, marca, claves de API, resultados e informes de uso, totalmente aislados del resto, mientras la facturación se queda a nivel de organización.

#Revender Didit

Si quieres integrar Didit en tu propio producto y cobrárselo a tus clientes, eso es el modelo de reseller. Así funciona, en los términos que soporte da a todo el que pregunta:

• Crédito prepagado. Una compra inicial mínima de 5.000 USD, prepagada, con un acuerdo de un año. El crédito nunca caduca, está a nivel de tu organización y se consume entre todos los clientes finales que incorpores, y lleva un descuento por volumen que crece con el importe.
• El panel lo construyes tú. Integras la API de Didit en tu propio front-end y tus clientes gestionan ahí sus flujos, su marca y sus roles. Didit no ofrece una copia de marca blanca de la Business Console; las pantallas de verificación que ven tus usuarios finales sí pueden llevar tu marca (consulta marca blanca), la consola no.
• Tu margen es tuyo. Tú fijas el precio que pagan tus clientes. Didit te factura por función completada a los precios unitarios fijados durante la vigencia del acuerdo.
• No es un programa de partners locales. Didit hace las demos, la incorporación y el soporte directamente con los clientes y no busca partners de distribución ni de implementación.

Si prefieres no gestionar la reventa, usa la opción de referidos: en la barra lateral de la Business Console abre Referidos, acepta los términos del programa y comparte tu enlace. Ganas una comisión del 10 % sobre cada depósito en efectivo que haga una organización referida, durante 36 meses desde su primer depósito, utilizable como crédito de Didit o cobrable por transferencia bancaria cuando madure, sin obligaciones de entrega ni de soporte. Puedes construir y probar tu integración en el plan gratuito antes de comprometerte con cualquiera de las dos.

#Eliminar una aplicación

Eliminar una aplicación elimina sus flujos de trabajo y su configuración. Sus datos de verificación siguen la política de retención y las reglas de eliminación de esos datos, no el ciclo de vida de la aplicación, así que si tu objetivo es borrar datos de clientes, elimina los datos de forma explícita en lugar de asumir que eliminar la aplicación lo hace. Consulta eliminar sesiones y datos personales.

#Todo es atribuible

Cada llamada a la API registra a qué aplicación pertenecía, en el registro de auditoría, durante 365 días. Eso es lo que hace que una estructura con varias aplicaciones sea auditable y no solo ordenada. Consulta cómo usar los registros de auditoría.