Cómo abrir un caso de soporte
Cómo abrir un caso de soporte
Esta guía es para los equipos que usan Soyio y necesitan ayuda con un caso concreto: qué contarnos y cómo identificar el caso sin compartir datos personales.
Si tu consulta es sobre un trámite con una empresa, contacta primero al canal de soporte de esa empresa. Escríbenos solo si tu consulta es sobre tu cuenta Soyio, por ejemplo un acceso con passkey.
Por dónde abrir un caso
Escríbenos a soporte@soyio.id o usa el chat del dashboard. Las dos vías llegan al mismo lugar y reciben el mismo tratamiento.
Qué identificador enviar
Casi todos los objetos de Soyio tienen un ID visible en el dashboard. Con ese ID encontramos el caso: vemos de nuestro lado los datos de la persona, el estado y el historial. Cuando no haya un ID a la vista, en la tabla indicamos qué mandar en su lugar.
| Tipo de caso | Qué mandarnos | Se ve como |
|---|---|---|
| Verificación de identidad | ID de la solicitud de divulgación, o del intento de validación | dreq_… · va_… |
| Derechos ARSOP (acceso, rectificación, etc.) | ID de la solicitud, o el identificador corto de 7 caracteres | dsreq_… · ABC1234 |
| Consentimientos | ID de la plantilla, del commit o de la acción | constpl_… · ccom_… · consact_… |
| REDEC | ID de la plantilla de consentimiento o del producto | constpl_… · prod_… |
| Webhooks | ID del webhook y el evento que falló | wh_… |
| Exportaciones | ID de la exportación | exp_… |
| Usuarios y roles del dashboard | Correo del integrante afectado y, si aplica, el nombre del rol | — |
| Prisma — entrevistas y levantamientos | La URL de la entrevista, copiada de la barra de direcciones. Si el problema abarca todo un levantamiento, su URL o su ID | prisma.soyio.id/sessions/… · UUID |
| Prisma — acceso de un integrante | El correo con que fue invitado y cuándo se envió la invitación | — |
| API en general | Endpoint, método, código de respuesta y cuerpos del request y de la respuesta sin claves de API ni datos personales | — |
Si el problema fue una llamada a la API y tu cliente HTTP muestra el X-Request-Id de la respuesta, agrégalo: con eso encontramos la petición exacta en nuestros registros.
Si no tienes el ID a mano, sirve tu propia referencia del usuario (user_reference), el identificador que tu sistema le asigna. No necesitamos saber quién es la persona para encontrar el caso.
dreq_ es una solicitud de divulgación (verificación de identidad). dsreq_ es una solicitud de derechos ARSOP.
Lo natural al reportar es decir «la entrevista de Fulana queda en loop», y así llegan casi todos los casos. Con la URL de la entrevista nos basta: identifica el caso sin nombrar a nadie. Si el problema es de una actividad puntual dentro de la entrevista, nombrarla por el título de la actividad y no por quién la respondió.
Qué ayuda a resolverlo más rápido
- Ambiente: sandbox o producción. Si dudas cuál es, revisa pruebas en sandbox.
- Fecha y hora aproximadas, con zona horaria
- Qué esperabas que pasara y qué pasó
- El identificador del objeto involucrado, según la tabla de arriba
Capturas de pantalla
Las capturas son la forma más rápida de mostrarnos un problema y las recibimos con gusto. Antes de enviarlas:
- Recorta o tapa los datos de tus usuarios que aparezcan en pantalla: nombre, RUT, correo, teléfono. Para entender el problema nos basta el mensaje de error y el ID.
- Revisa que no se vea una clave de API, ni en la barra de direcciones, ni en la consola, ni en un header.
Datos de tus usuarios finales
No necesitas enviarnos datos personales de tus usuarios finales. Con el ID del objeto los vemos en nuestro sistema, con el control de acceso que corresponde.
Por eso la recomendación es simple: identifícanos el caso con el ID y cuéntanos qué pasó, y deja los datos de la persona fuera del mensaje.
Tu clave de API
Nunca la incluyas, ni en el texto, ni en una captura, ni en un ejemplo de request. Si ya la enviaste, rótala desde el dashboard y avísanos para eliminar el mensaje. Revisa cómo gestionar tus API keys.