SDK

Siete SDK de cliente oficiales envuelven el mismo contrato REST que describe esta documentación, y la API sigue siendo curl-first: aquí nada exige uno.

Todos los ejemplos de esta documentación usan curl, porque la API es REST simple con autenticación por token de portador: sirve el cliente HTTP de cualquier lenguaje. Los SDK existen para ahorrarte el código repetitivo: tipos de petición y respuesta, la taxonomía de errores tipados (validación, autenticación, permiso, no encontrado, límite de peticiones) y la firma HMAC de las peticiones calculada por ti.

Lenguajes

Cada SDK es un port idiomático del cliente Node de referencia: mismas llamadas, mismo contrato de red, convenciones de nombres locales.

Qué cubren

Los siete exponen la misma superficie, la que alcanzan una clave de API o un token de OAuth:

• Crear una sesión, volver a leerla y consultar su estado en vivo (sessions.create, sessions.get, sessions.status).
• Reactivar una invitación caducada en el mismo sitio, o emitir un enlace totalmente nuevo que anula el anterior, cambiando opcionalmente el canal o el destinatario (sessions.reshare).
• Protección del invitado: leer la contraseña o el código rotatorio del momento, cambiarlo tras la creación y liberar un bloqueo, con o sin rotar el secreto.
• Emitir tokens de vista de agente para incrustar el visor en vivo en tu propia interfaz.
• Listar las capturas de una sesión y descargar una como PNG en base64.
• Verificar el token de OAuth actual e intercambiar un código de autorización por uno (función independiente: se ejecuta antes de que exista cliente alguno).
• Firma HMAC opcional de las peticiones: define un secreto de firma y cada petición lleva las cabeceras X-SeeItLive-Signature y X-SeeItLive-Timestamp.