Robot de WeCom

Despliega tu propia instancia de cuenta de WeCom, inicia sesión escaneando con WeCom móvil y lee la cuenta, los contactos, las conversaciones y los mensajes sincronizados localmente mediante REST API o MCP. La instancia corresponde a una cuenta normal de WeCom, sin necesidad de configuración de servidor privado ni de dominio de correo empresarial. Actualmente está en Alpha. La lectura de cuentas ha completado la validación con conversaciones reales; el envío de texto propio y la lectura de eventos han completado la aceptación real; las operaciones con otros contactos, grupos y la recuperación de nuevas instancias aún deben completar la aceptación en el entorno de despliegue. El envío de medios, las respuestas con cita, las menciones @ reales, la gestión de miembros de grupos y los acuses de entrega aún no están disponibles. Consulte el valor devuelto por /api/capabilities de la instancia.

​

Despliegue e inicio de sesión

Active el servicio en la categoría Deployment y seleccione el plan de duración de la instancia. Después del despliegue, abra la página de administración y escanee con WeCom de la propia cuenta; si se requiere confirmación móvil u otros pasos de inicio de sesión, abra el escritorio remoto e introduzca la contraseña de escritorio de esa instancia. Las credenciales de API y la contraseña de escritorio son independientes. Los datos de inicio de sesión se guardan en el disco de la instancia; al reconstruir el contenedor se conserva el disco; eliminar el disco eliminará la sesión local. Cada instancia se cobra de forma independiente y se ejecuta según la duración adquirida. Las llamadas REST / MCP no se cobran adicionalmente por mensaje; el precio real prevalece según la página del plan. Actualmente se toma como referencia predeterminada el plan de duración de los robots de WeChat; antes de la apertura final, se debe confirmar la fijación de precios en combinación con los recursos de ejecución.

​

API y MCP

Utilice la dirección API de la instancia en la página de administración; todas las interfaces de cuenta llevan Authorization: Bearer <token API de la instancia>. Estas rutas pertenecen a instancias exclusivas, no a una puerta de enlace API compartida. La dirección MCP es la dirección de la instancia más /mcp/, utilizando el mismo token Bearer. El cuerpo de envío contiene target, type: "text" y text. target acepta ID de conversación, ID de contacto, ID de usuario empresarial o nombre completo único; se priorizan los ID; si el nombre mostrado aún no permite una localización única, la instancia rechazará la operación y no adivinará el destinatario. Para los contactos sin conversación local, primero se abrirá una conversación a través del cliente, y se enviará después de verificar el ID de conversación real. El encabezado de solicitud Idempotency-Key tiene entre 8 y 128 caracteres de letras, números o _.:-. Las solicitudes repetidas para la misma operación deben reutilizar la misma clave y el mismo cuerpo de solicitud. Cambiar target por una matriz targets permite enviar secuencialmente a 1–50 destinos especificados de forma explícita. No se pueden proporcionar ambos simultáneamente. Todos los destinos completan primero la resolución de identidad; se rechazarán distintos alias que apunten al mismo objeto. Después de que falle un destino, se detendrán los envíos posteriores; el resultado de la tarea registra por elemento succeeded, failed, unknown o not_attempted; no trate el éxito parcial como éxito completo. Este flujo aún debe completar la aceptación real de contactos especificados en el entorno de despliegue. Las tareas pueden estar en queued, running, submitting, succeeded, failed, unknown o cancelled. succeeded indica que, después del envío, se encontró el texto exacto y el ID de mensaje del servidor en el registro de la conversación correspondiente; delivered sigue siendo null y no representa que la otra parte lo haya recibido. unknown indica que el resultado no está claro; revise los registros históricos y no repita el envío con una clave nueva. La instancia no reintentará automáticamente las tareas interrumpidas. El historial solo contiene contenido ya sincronizado por el cliente y no puede garantizar todo el historial. Los mensajes no textuales pueden devolver un tipo unknown; la descarga de archivos adjuntos aún no está disponible. Los eventos conservan las 10.000 entradas más recientes; gap indica que el cursor ha superado la ventana de retención. La primera conexión no reproducirá el historial antiguo como mensajes nuevos. server_accepted y server_id del historial de mensajes pueden utilizarse para verificar si el servidor ha aceptado el mensaje local; cuando solo aparece un registro local sin ID de servidor, no se puede determinar que el envío haya tenido éxito. Estos campos no representan que el receptor lo haya recibido o leído. Los registros de eventos conservan el estado en el momento de su generación; para consultar el estado de confirmación actual, se debe utilizar la interfaz de historial de mensajes.

​

Cuenta y credenciales

Inicie sesión únicamente en cuentas que el propietario tenga autorización para operar. Configure el token API en aplicaciones de confianza; puede acceder a los datos de cuenta de esa instancia. No publique contraseñas, códigos QR ni capturas de pantalla de chats en lugares públicos. Pausar la instancia interrumpirá los eventos en tiempo real. Después de cerrar sesión en la cuenta o eliminar el dispositivo desde el móvil, será necesario iniciar sesión de nuevo. La entrada de texto actual solo admite una línea; los saltos de línea se rechazarán explícitamente antes del envío. Cuando el cliente requiera verificación de seguridad o volver a iniciar sesión, el propietario de la cuenta debe completarlo en el escritorio remoto; la instancia no eludirá la verificación. Las tareas tras una interrupción de verificación pueden devolver unknown; consulte primero el registro de mensajes y no reenvíe con una nueva clave de idempotencia. Después de detectar un aviso de verificación de seguridad, el cierre de sesión de la cuenta o cambios, la cola de automatización se pausará de forma persistente. Después de completar la verificación móvil, puede continuar las tareas aún no ejecutadas mediante «Reanudar después de la verificación» en la consola de la instancia; las tareas ya enviadas pero con resultado incierto no se reenviarán. El trabajo remoto normal también puede activar la verificación de seguridad de WeCom. La ventana de 24 horas sin bloqueo adicional después de la verificación indicada en la documentación oficial no significa que se haya eliminado la detección, ni significa que la instancia pueda garantizar una operación desatendida a largo plazo.