Pruebas y puesta en producción

Todavía no hay entorno de pruebas

La versión 1.0a no tiene entorno de pruebas ni claves de prueba. Cada clave lee un equipo real, y todo lo que devuelve lleva livemode: true. La API es de solo lectura, así que ninguna petición puede cambiar datos en Totem: probar es seguro siempre que trates lo que lees como datos personales reales.

Dónde probar

Empieza con un equipo que solo contenga datos ficticios, y usa datos reales solo cuando estés listo para pasar a producción.

Un equipo dedicado con datos ficticios. Usa un equipo de Totem separado que solo contenga contactos ficticios y crea una integración para él. Su clave sigue siendo una clave real, y el equipo necesita lo mismo que uno de producción: una organización cuyo plan incluya la API, la configuración legal completada, un sector de actividad que no sea sensible y un administrador que cree la integración (el Inicio rápido los enumera). La API es de solo lectura, así que los datos de prueba se crean en el propio Totem: añade a mano algunos leads con nombres ficticios y con teléfonos y direcciones de correo de los rangos de más abajo, y después llama, escribe o pide una cita al equipo de pruebas tú mismo para generar llamadas, conversaciones y citas.
Tu propio equipo. También puedes desarrollar con los datos reales de tu equipo y tu propia clave. Guarda esos datos solo en sistemas cubiertos por tus acuerdos de tratamiento de datos y borra las copias de prueba al terminar.

Datos de ejemplo

El kit del integrador incluye la descripción de la API y objetos de ejemplo:

openapi.json describe todos los endpoints y campos;
fixtures.json contiene objetos de ejemplo de cada tipo, todos con livemode: false.

Carga esos datos de ejemplo en tus pruebas unitarias antes de llamar a la API. Los ejemplos de esta documentación y del kit solo usan contactos ficticios:

teléfonos del +1 202-555-0100 al +1 202-555-0199;
direcciones de correo electrónico del dominio example.com.

Usa los mismos rangos en tus propios datos de prueba, para que ninguna prueba pueda llegar nunca a una persona real.

Qué probar antes de pasar a producción

Haz cada comprobación sobre tu propio código, con los datos de ejemplo o con un equipo de pruebas. Sincroniza una copia explica el comportamiento que demuestra cada una.

Aplicar el feed

Idempotencia. Aplica dos veces la misma página del feed: la segunda vez no debe cambiar nada.
Versiones antiguas. Entrega un elemento con una version menor que la que tienes: debe ignorarse.
Recuperación tras un fallo. Detén la sincronización después de guardar una página y antes de guardar su cursor, y vuelve a arrancarla: la página repetida no debe cambiar nada.
Eliminaciones. Una eliminación debe borrar el registro y, si es un lead, su atribución, su respuesta y sus actividades. Después, entrega una versión anterior del mismo registro: debe seguir borrado.
Resincronización completa. Tira el cursor y haz la resincronización completa: los registros que falten en la nueva copia deben desaparecer.
Valores desconocidos. Un valor de enumeración o un código de error que no conoces no debe detener la sincronización.

Errores y límites

Un equipo que no está listo. Con una clave que lee dos equipos, haz que uno responda 409 capture_not_ready: el otro debe seguir sincronizándose en la misma ejecución, y el primero debe conservar su cursor.
Equipos que entran y salen. 404 team_not_accessible debe borrar los datos del equipo solo cuando GET /v1/teams confirme que el equipo ya no está. Un 403 debe conservar los datos y el cursor.
Límite de frecuencia. Un 429 rate_limited debe esperar lo que indique Retry-After y después continuar con el mismo cursor.
Cuota diaria. Un 429 quota_exceeded debe detener la sincronización hasta las 00:00 UTC y reanudarla entonces con el mismo cursor. Asegúrate de que el proceso que espera no pueda solaparse con la siguiente ejecución programada.

Contactos

Permisos de contacto. Ningún sistema al que envíes datos debe contactar con un lead que tenga contact_permissions.do_not_contact: true.
Consentimiento desconocido. Un lead con whatsapp_consent: null no debe recibir mensajes de WhatsApp como si hubiera aceptado.

Ensaya la rotación de una clave

Rota una clave una vez antes de depender de ella, para que la primera rotación real sea rutina:

En Ajustes → Desarrolladores, elige Rotar clave y mantén la clave anterior durante 1 hora.
Despliega la clave nueva en tu servidor, igual que lo harás en producción.
Comprueba que tu sincronización sigue funcionando con la clave nueva.
Cuando haya pasado esa hora, comprueba que la clave antigua responde 401 key_expired y que ya no la usa ninguno de tus sistemas.

Autenticación explica cómo rotar y revocar claves.

Comprobar la disponibilidad

GET /v1/health indica si la API está funcionando. No necesita clave ni devuelve datos, así que úsalo para la monitorización. Compruébalo con GET: el cortafuegos situado delante de la API responde a HEAD con un 404 simple. Llámalo sin cadena de consulta: cualquier parámetro, aunque sea para evitar la caché, recibe 400 invalid_request. Su cabecera de respuesta Totem-Release indica la versión del servicio que respondió; inclúyela cuando nos avises de una incidencia. Para comprobar una clave, llama a GET /v1/me.