Saltar al contenido principal

Integración con ID Externo

La API de Ozzie soporta dos patrones de integración distintos. Puedes elegir el que mejor se adapte a tu arquitectura — o combinar ambos dentro de la misma cuenta de cliente.


Dos Patrones de Integración

Flujo A — Creación explícita de usuario

Primero creas un registro de usuario llamando a POST /v1/users, recibes un UUID de Ozzie (ozz_usr_...) y lo usas en todas las solicitudes posteriores.

POST /v1/users → devuelve id: "ozz_usr_abc123"
POST /v1/users/ozz_usr_abc123/financial-intake → usa UUID de Ozzie
POST /v1/users/ozz_usr_abc123/plan/generate → usa UUID de Ozzie
POST /v1/users/ozz_usr_abc123/chat/messages → usa UUID de Ozzie

Recomendado para: integraciones donde quieres control total sobre la creación de usuarios, o donde necesitas almacenar el UUID de Ozzie en tu propia base de datos.


Flujo B — Aprovisionamiento automático con ID externo

Omites la creación de usuarios por completo. Usa el formato external:{tu_id} como parámetro de ruta {user_id} en cualquier endpoint. En la primera llamada, Ozzie crea automáticamente el usuario en segundo plano y continúa procesando la solicitud.

POST /v1/users/external:usr_8821/financial-intake → usuario creado automáticamente en la 1ª llamada
POST /v1/users/external:usr_8821/plan/generate → mismo usuario, sin paso de creación
POST /v1/users/external:usr_8821/chat/messages → mismo usuario

Recomendado para: integraciones donde no quieres gestionar un paso de creación de usuario separado, o donde estás conectando una base de usuarios existente sin migrar IDs.

info

No se necesita ninguna configuración o bandera para usar el Flujo B. Cualquier valor no-UUID con prefijo external: se trata automáticamente como una búsqueda por ID externo. Si el usuario aún no existe, se crea silenciosamente.


Cómo funciona external:{id}

Cuando Ozzie recibe una solicitud con external:{tu_id} como parámetro user_id, él:

  1. Elimina el prefijo external: y extrae tu ID
  2. Busca al usuario por (api_client_id, external_user_id)
  3. Si lo encuentra → procesa la solicitud con el usuario encontrado
  4. Si no lo encuentra → crea automáticamente un nuevo usuario con external_user_id = tu_id y created_via = "api_external", luego continúa procesando la solicitud

El usuario creado automáticamente comienza con onboarding_stage: "financial_intake". Ozzie avanza el estado automáticamente después del intake financiero y la generación del plan, igual que con los usuarios creados via POST /v1/users.


Elegir entre los dos flujos

SituaciónPatrón recomendado
Quieres registrar usuarios con nombre, correo y teléfono antes de cualquier interacciónFlujo A — POST /v1/users
Tienes una base de usuarios existente y quieres cero fricción en la migraciónFlujo B — external:{id} en cualquier endpoint
Estás construyendo un bot de WhatsApp o interfaz conversacionalFlujo A — establece phone en la creación para la correspondencia de número
Eres una fintech que hace proxy de solicitudes para tus propios usuariosFlujo B — usa el ID de tu base de datos como ID externo
Necesitas ambos patrones en la misma integraciónCombínalos libremente — cada usuario puede ser creado de cualquier manera

Flujo B — Ejemplo completo

Este ejemplo envía el intake financiero, genera un plan e inicia un chat — todo sin ninguna llamada a POST /v1/users:

# Paso 1 — Enviar intake financiero (usuario creado automáticamente en esta llamada)
curl -X POST https://api.ozzieapp.com/v1/users/external:usr_8821/financial-intake \
-H "Authorization: Bearer TU_BEARER_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"monthly_income": 5000,
"monthly_expenses": 3200,
"financial_goal": "savings"
}'

# Paso 2 — Generar plan
curl -X POST https://api.ozzieapp.com/v1/users/external:usr_8821/plan/generate \
-H "Authorization: Bearer TU_BEARER_TOKEN" \
-H "Content-Type: application/json" \
-d '{}'

# Paso 3 — Chat
curl -X POST https://api.ozzieapp.com/v1/users/external:usr_8821/chat/messages \
-H "Authorization: Bearer TU_BEARER_TOKEN" \
-H "Content-Type: application/json" \
-d '{"message": "¿Cuánto debería ahorrar este mes?"}'

Recuperando un usuario aprovisionado automáticamente

Los usuarios creados via Flujo B pueden recuperarse en cualquier momento usando GET /v1/users/external:{id} o por su UUID de Ozzie una vez que lo conozcas:

curl https://api.ozzieapp.com/v1/users/external:usr_8821 \
-H "Authorization: Bearer TU_BEARER_TOKEN"
{
"object": "user",
"data": {
"id": "ozz_usr_01HX9KZMR4P5JQNBVT7YCW3DE",
"external_user_id": "usr_8821",
"name": null,
"email": null,
"phone": null,
"language": "en",
"onboarding_stage": "active",
"created_at": "2026-05-06T10:00:00Z"
}
}

Los usuarios aprovisionados automáticamente comienzan con name, email y phone como null. Puedes enriquecer el registro más adelante — contacta a commercial@ozzieapp.com si necesitas un endpoint de actualización de usuario.


Combinando ambos flujos

Ambos patrones son totalmente compatibles dentro de la misma cuenta de cliente de API. Algunos usuarios pueden crearse explícitamente via POST /v1/users (p.ej., usuarios que se registran con nombre y correo), mientras otros se aprovisionan automáticamente via external:{id} (p.ej., usuarios anónimos o importados de un sistema existente).

La única restricción es que external_user_id debe ser único por cliente de API. Un POST /v1/users explícito con el mismo external_user_id que un usuario ya aprovisionado automáticamente devolverá 409 CONFLICT.


Consideraciones de seguridad

  • El prefijo external: se resuelve después de la autenticación. Las solicitudes no autenticadas no pueden usarlo.
  • Los usuarios aprovisionados automáticamente via Flujo B están vinculados a tu cliente de API. Otro cliente no puede acceder a ellos aunque conozca el external_user_id.
  • Los límites de tasa se aplican igualmente a ambos flujos. El aprovisionamiento automático de un nuevo usuario no consume una llamada de API extra — es parte de la misma solicitud.