Historial de cambios y versiones

#Versiones

La versión está en la dirección: /api/v1. Un flujo o una integración creados sobre v1 no se tienen que rehacer cuando AttendBeacon cambia, así que dentro de v1:

• Se añade, nunca se quita. Operaciones nuevas, campos nuevos en las respuestas, parámetros opcionales nuevos, valores nuevos en una lista, como un tipo de webhook o un código de error. Escribe código que ignore lo que no conoce.
• Nunca se renombra ni se elimina, una vez publicado: un campo, una operación, un ámbito, un código de error o un tipo de webhook.
• Un cambio incompatible es v2. Se anuncia aquí y por correo a cada espacio de trabajo con una clave al menos seis meses antes de que cambie v1, y v1 sigue funcionando durante esos seis meses.
• Lo obsoleto se marca como deprecated en la descripción OpenAPI y se indica aquí, con la fecha en que desaparece.

No son cambios en este sentido: el orden de los campos en un cuerpo, el texto de detail (decide según code), las cabeceras de respuesta nuevas y la corrección de una respuesta que contradecía esta documentación.

La descripción OpenAPI 3.1 en /api/v1/openapi.json es la API tal como es ahora; info.version cambia con cada novedad.

#2026-10-15: v1.1, la plataforma para desarrolladores

• Ámbitos por área. Los ámbitos de una clave son ahora un área más un tipo de acceso (events:read, attendees:write), y los datos personales tienen su propio ámbito, people:read. Las claves creadas antes conservan exactamente lo que podían hacer.
• Las claves caducan y quedan registradas. Una clave puede caducar a los 30, 90, 180 o 365 días. Cada llamada aparece en Actividad de las claves, rechazos incluidos.
• Detalles de problema. Los rechazos son application/problem+json según RFC 9457, con un code estable; error se mantiene junto a detail para los flujos creados antes.
• Cursores y sincronización. Todas las listas responden con nextCursor y hasMore; las listas de cosas que cambian aceptan updatedSince. page y pageSize siguen funcionando donde funcionaban.
• Reintentos y cambios seguros. Idempotency-Key en todos los POST; ETag en los recursos individuales, If-None-Match e If-Match.
• Cabeceras de límite de solicitudes. RateLimit, RateLimit-Policy y X-RateLimit-* en cada respuesta, y Retry-After con un 429.
• Operaciones nuevas: el espacio de trabajo; crear eventos en borrador, cambiar sus datos básicos y publicarlos; estadísticas del evento y ritmo de ventas; tipos de entrada (y cambiarlos), complementos y códigos de descuento (y crearlos); un pedido; buscar asistentes; recuentos de las puertas; sesiones (y añadirlas y cambiarlas), salas, itinerarios y ponentes; patrocinadores y niveles de patrocinio; propuestas a la convocatoria de ponentes; equipo y turnos; encuestas, sus resultados y las valoraciones de sesiones; facturas y facturas rectificativas; el resumen del presupuesto; la clasificación del kit para compartir; comunidades y sus miembros; puntos de conexión de webhook, sus entregas, pruebas y secretos, y los tipos de evento con los esquemas de sus cargas útiles.
• Módulos. El módulo desactivado de un evento responde 409 moduleOff en sus endpoints. Esto también se aplica a las puertas, los escaneos en puerta y el registro de entrada (el módulo de registro de entradas) y a los leads (el módulo de leads), que ya lo hacían antes.
• Personas. Sin people:read, los asistentes, los compradores, el equipo y los miembros son ids; los leads y la búsqueda de asistentes lo necesitan. Quien ha eliminado sus datos aparece como erased, sin nada personal.
• Descripciones. /api/v1/openapi.json es ahora OpenAPI 3.1, con ejemplos y todos los rechazos; la descripción Swagger 2.0 que importa Power Platform está en /api/v1/swagger.json.
• El servidor MCP en /mcp, para asistentes de IA.

#2026-10-12: v1.0

• Eventos, asistentes con sus respuestas, pedidos y escaneos en puerta de un espacio de trabajo, con updatedSince.
• Inscribir a alguien con una entrada gratuita, cancelar una entrada y registrar la entrada de alguien.
• Suscripciones para Power Automate, Zapier y Make (/hooks), y webhooks firmados según Standard Webhooks.
• Preguntas de inscripción, su esquema JSON, tipos de entrada, puertas y leads recientes, para los selectores y campos de los flujos.