Anthropic anunció el 20 de octubre de 2026 los perfiles de cliente y los webhooks de organización en sus notas de la plataforma Claude. Para una empresa que ofrece Claude dentro de su producto, la novedad permite identificar a qué cliente corresponde cada petición. Hay una diferencia decisiva de disponibilidad: la documentación de webhooks dice que la entrega de eventos todavía no está activa.
Atribuir tráfico antes de necesitar una restricción
Según la documentación de perfiles, una medida por uso indebido puede aplicarse al cliente identificado en vez de a toda la organización. El perfil no se factura ni cambia los precios. Identifica al destinatario del servicio; no contiene sus conversaciones.
En la API directa se crea una vez mediante POST /v1/user_profiles, se guarda el identificador uprof_… y se adjunta a cada petición con anthropic-user-profile-id. El tipo application representa a un usuario del producto; passthrough, a una empresa a la que se revende acceso. El perfil pertenece a la organización, no al espacio de trabajo. Anthropic indica mantener el uso interno en otra organización.
Una precaución de integración: crear perfiles no es idempotente, es decir, repetir la petición puede crear otro. Reutilizar reference_id no evita el duplicado. Conviene conservar la relación entre cliente e identificador.
Ejemplo: dos comercios dentro de una plataforma
Ejemplo hipotético, no ejecutado por Puntoes: una aplicación de soporte atiende a los comercios A y B. Antes de integrar la función, el equipo debe decidir si está ofreciendo un producto a usuarios o revendiendo acceso a empresas: esa decisión determina qué representa el perfil.
Nuestro criterio de diseño sería resolver el perfil en el servidor a partir de la sesión autenticada. No aceptaríamos un identificador arbitrario enviado por el navegador: permitiría atribuir una petición al cliente equivocado. También revisaríamos las rutas menos visibles, como trabajos en segundo plano, para detectar peticiones que salen sin atribuir.
Este ejemplo no demuestra que la integración funcione ni garantiza aislamiento de datos. Propone comprobaciones para una prueba posterior. Identificar al cliente tampoco sustituye los permisos que la aplicación necesita para decidir qué documentos puede consultar cada persona.
Webhooks: se puede preparar el receptor, no confiar aún en sus avisos
Un webhook es una notificación que un servicio envía a una dirección de tu aplicación. Los webhooks de organización de Claude están en beta con la cabecera webhooks-2026-10-07; el acceso se solicita al equipo de cuenta. La documentación permite registrar receptores y preparar su manejo, pero advierte expresamente que los endpoints registrados no reciben nada por ahora.
Los dos eventos previstos corresponden a la apertura y resolución de restricciones o bloqueos sobre perfiles. No constituyen un registro de toda la actividad de Claude. El contrato documentado contempla duplicados y eventos fuera de orden: indica deduplicar por identificador del evento y consultar el estado actual del perfil. Estas son condiciones del diseño documentado, no entregas observadas por Puntoes.
Para el ejemplo anterior, no pondríamos un proceso crítico a esperar un aviso de esta beta. Primero comprobaríamos la disponibilidad efectiva en la organización. La documentación consultada el 21 de octubre no aporta una fecha de activación que permita programarla como segura.
El cambio trata de atribución de clientes y medidas de seguridad. Si el problema es coordinar tareas, el antecedente sobre workflows dinámicos de Managed Agents aborda otra capa de la plataforma. Esta noticia se centra en la API directa; una integración en otro proveedor exige comprobar sus reglas específicas.