Casos borde

Colisiones de RUT: RUT_OTHER_EMAIL

Cuando un RUT ya está registrado en Skip bajo otro correo, GET /api/spot/widget/{token} devuelve:

• HTTP 409
• Un payload de recuperación que incluye el correo enmascarado en archivo.

El widget renderiza una pantalla "este RUT pertenece a otra cuenta" y le ofrece al paciente un flujo de recuperación (iniciar sesión con el correo original o contactar soporte). Tu página no necesita gestionar esto — aparece como SPOT_WIDGET_ERROR si el paciente no puede completar.

Para la matriz completa de combinaciones email/RUT — qué combinaciones permite Skip y cuáles bloquea — el documento autoritativo es interno. Pídele al equipo Skip la matriz email/RUT si estás diseñando un flujo que necesita gestionar estos casos explícitamente.

Tokens expirados

Los tokens estándar expiran 1 hora después del minteo. Si el paciente vuelve después (ej. desde un link guardado), el iframe recibe 410 Gone. Dos opciones:

1. Mintear long-term token. Pasa long_term_token=true en POST /api/spot/widget. El TTL pasa a 30 días.
2. Mintear on demand. Que la URL de recuperación que pongas en metadata.retry_url mintee un token nuevo.

Estado de suscripción

Si necesitas saber si un paciente ya es Skip Pro antes de decidir si renderear el widget:

GET /api/spot/is_user_subscribed?public_key={tu_public_key}&rut=12345678-9

Respuesta:

{
  "is_subscribed": true,
  "is_free_trial": false
}

Lógica que aplica Skip:

1. Plan activo (sin ended_at) → is_subscribed=true, is_free_trial=false.
2. Sin plan activo, menos de 2 boletas enviadas → is_subscribed=true, is_free_trial=true.
3. Sin plan activo, 2+ boletas → is_subscribed=false, is_free_trial=false.

Verificación de conversión de lead (partners de referidos)

Si refieres pacientes a Skip y necesitas confirmar que efectivamente empezaron a usar el producto (no solo se registraron):

GET /api/spot/user/{user_id}/check-if-successful-lead

Respuesta:

{
  "is_successful_lead": true,
  "message": "El usuario envió al menos un reembolso."
}

"Lead exitoso" significa que el usuario envió al menos una boleta — i.e., cruzó de registrado a activo.

Por qué el widget AAPD hace un POST /payment temprano

Si embebes Spot dentro de un flujo AAPD (con order_token seteado), notarás que el widget llama POST /orders/{order_hash}/payment antes de la pantalla de captura final. Es intencional: esa llamada también funciona como probe de readiness además de creación del pago.

Si vuelve un 400 con processor_customer_identity_not_validated o processor_payment_method_not_found, el widget interpreta la respuesta como señal de control de flujo y renderiza la pantalla apropiada (validación de identidad o setup de pago). Un 400 de esa llamada temprana no indica integración rota. No tienes que gestionarlo.