Preguntas frecuentes

Respuestas rápidas a las preguntas más comunes al integrar Spot y AAPD.

Este FAQ se llena con preguntas reales que recibimos en el piloto. Hoy es liviano — vuelve después de Q3 2026 para ver la versión completa.

Generales

Sí. Skip y tu empresa firman un acuerdo comercial antes de emitir credenciales de producción. Las credenciales de staging las entregamos antes para que puedas explorar.

¿Skip cobra por integración?

No hay fee de integración. La economía está en las comisiones por orden (AAPD) o en el modelo per-paciente (Spot, según agreement configurado). Tu account manager te confirma los porcentajes en el contrato.

¿Funciona en otros países que no sean Chile?

Hoy no. Spot y AAPD están diseñados alrededor de RUT, ISAPRE y el sistema de salud chileno. Estamos abiertos a conversar para LATAM, pero la roadmap pública aún no incluye expansión.

Técnicas

¿Por qué hay dos dominios de API (backend.getskip.ai y pay.getskip.ai)?

Skip expone dos superficies: backend.getskip.ai cubre Spot, ISAPRE y notificaciones; pay.getskip.ai (SkipPay) cubre el modelo de órdenes y pagos AAPD. Como integrador hablas con ambos; la documentación te indica en cada endpoint cuál usar. Qué vive detrás de cada dominio es un detalle de implementación.

¿Skip tiene SDK oficial?

No. La superficie es chica (≈15 endpoints en Spot, ≈9 en AAPD), las requests son JSON estándar con Bearer auth, y este sitio incluye snippets en cURL, JavaScript, Python, PHP y Go para webhooks. Un SDK añadiría más mantenimiento que valor.

¿Puedo testear sin afectar a pacientes reales?

Sí — el ambiente de staging corre los pagos en sandbox, la presentación ISAPRE simulada y WhatsApp redirigido a un número de pruebas. Para completar un pago de prueba en el widget usa las tarjetas de prueba. Lee Conceptos → Ambientes para detalle.

¿Hay un panel para ver o gestionar mis órdenes AAPD?

Skip tiene un panel de administración interno para órdenes AAPD (staging y producción), pero no es self-service ni tiene URL pública. Si necesitas acceso para una operación puntual, coordínalo con el equipo de Skip. Para leer o modificar órdenes de forma programática, usa la API con tu client_secret. Ver Conceptos → Administración de órdenes.

Spot: boletas y onboarding

¿Qué eventos emite el widget para medir onboarding iniciado y completado?

El widget emite eventos postMessage a tu página (ver Widget):

  • SPOT_USER_CREATED — el paciente terminó el onboarding ({ user_id, rut }).
  • SPOT_WIDGET_CLOSED — cerró el widget sin terminar.
  • SPOT_WIDGET_ERROR — error irrecuperable ({ code, message }).

No hay un evento "onboarding iniciado": el inicio lo cuentas cuando montas el iframe. Tampoco hay un webhook servidor→servidor. SPOT_USER_CREATED es una señal de frontend; si tu métrica de adopción necesita certeza, confírmala server-side (ver la pregunta de consulta por RUT, o que /api/spot/gastos deje de responder 404).

¿Puedo consultar por RUT si un paciente ya es beneficiario de Skip?

Sí. GET /api/spot/is_user_subscribed?public_key=…&rut=… responde { is_subscribed, is_free_trial }, útil como pre-chequeo antes de emitir o enviar la boleta. De todas formas, la reja definitiva es el propio endpoint de boletas: si el RUT no es beneficiario, POST /api/spot/gastos devuelve 404 beneficiary_not_found.

¿Aceptan XML además de PDF?

No. Las boletas se suben como PDF o imagen (JPEG, PNG, WebP, HEIC/HEIF), entre 1 y 5 archivos, máximo 2 MB cada uno. XML no está soportado hoy.

Enviamos una boleta y responden 200 OK. ¿Significa "recibida y validada"?

El 200 significa recibida y encolada, no validada. Skip acepta el archivo y encola el procesamiento; la extracción con IA y la presentación a la ISAPRE ocurren después, de forma asíncrona, y pueden fallar sin que aparezca en tu respuesta (hoy no hay webhook público de status; esos fallos van a colas internas de Skip y a tu account manager). Puedes marcar internamente "enviado a Skip" con el 200, pero no "procesado correctamente". Ver Boletas → processed_files.

El paciente aún no está registrado y recibo 404. ¿Qué hago?

El 404 beneficiary_not_found significa que ese RUT todavía no es beneficiario Skip. Recomendación: guarda la boleta y reintenta cuando el paciente complete su onboarding. La correlación paciente↔boleta se hace por RUT (normalizado). Ejemplo: si el paciente paga y se registra el mismo día, al emitirse la boleta esa noche ya es beneficiario → 200; si no completó el registro, seguirás recibiendo 404 hasta que lo haga.

¿Nos dan credenciales de prueba (pk_test_*) y documentación del widget?

Sí. Al onboardearte recibes ambos pares de credenciales: staging (pk_test_*) y producción (pk_live_*). En staging los pagos corren en sandbox y WhatsApp va a un número de pruebas. La documentación del widget está en Guías → Spot Widget; los ambientes y URLs base en Conceptos.

Idempotencia: ¿deduplican por (public_key, receipt_id)?

No. Skip deduplica por el contenido del archivo (hash SHA256, dentro del mismo paciente), no por receipt_id. receipt_id se guarda solo como referencia tuya. Para reintentar tras un fallo de red sin crear un gasto duplicado (ni un segundo WhatsApp al paciente), reenvía el mismo archivo, byte a byte — ahí actúa la deduplicación. Si regeneras el PDF, el hash cambia y Skip lo tratará como una boleta nueva.

On this page