• Cambiado. En Listar repositorios de la instalación de la aplicación, List Branches, List Check Run Annotations, List Check Runs For Commit, List Check Runs For Suite, List Check Suites For Commit, List Commit Files, List Comparison Files, List Namespace Grants, List Namespaces, List Pull Request Files, List Pull Requests, List Repos y List Repository Grants, un pageSize enviado junto con un pageToken se aplica a esa página, y una solicitud posterior que omite pageSize conserva el tamaño de página anterior. List Commit Files y List Comparison Files ya no rechazan con InvalidArgument (HTTP 400) un pageSize posterior distinto del de la primera solicitud, y los demás endpoints ya no lo ignoran. Todo lo demás a lo que está vinculado un token de página, como el repositorio, los filtros y la versión de la pull request, debe seguir coincidiendo.

• Cambiado. Merge Pull Request devuelve Aborted (HTTP 409 Conflict) en lugar de InvalidArgument (HTTP 400) cuando la rama de cabecera de la pull request ha avanzado más allá de la cabecera de su version más reciente; por ejemplo, porque se integró un push que Origin aún no había registrado como nueva versión. Es la misma respuesta que se obtiene con un expectedHeadSha obsoleto. En ninguno de los dos casos se fusiona nada; vuelve a intentarlo cuando Get Pull Request indique la nueva cabecera en version.headSha.

• Cambio incompatible. Las referencias de versión de hilos de comentarios y de revisiones ya no incluyen createdAt; solo contienen number, headSha y baseSha de la versión. Esto afecta a thread.version en List Pull Request Comments, Get Pull Request Comment, Create Pull Request Comment y Update Pull Request Comment; a version en Update Pull Request Thread; a pullRequestVersion en List Pull Request Reviews, Create Pull Request Review, Update Pull Request Review y Dismiss Pull Request Review; y a los mismos campos en los payloads pull_request.comment.created y pull_request.review.*. Migración: allí donde tu integración leía createdAt de la versión de un hilo o de una revisión, léelo ahora de version en Get Pull Request o en el payload de ciclo de vida pull_request.* que registró esa versión, emparejando por number.
• Añadido. Las versiones de pull request incluyen potentialMergeCommit, la fusión de prueba que Origin realiza de esa versión: state es prepared, merge_conflict o unknown, y una fusión prepared añade el sha del commit de fusión y baseSha, la punta de la rama base sobre la que se generó. Se devuelve en version en List Pull Requests, Get Pull Request, Create Pull Request, Update Pull Request y Merge Pull Request, y se incluye en los payloads de ciclo de vida pull_request.*, de modo que un receptor de webhooks conoce la vista previa de la fusión sin necesidad de llamar a Get Git Ref. Cada evento incluye el valor vigente en el momento de su emisión, así que interpreta unknown como un valor aún desconocido y vuelve a consultar la pull request.
• Añadido. Create Installation User Token emite un token de usuario de la instalación que actúa en nombre de un miembro habilitado del espacio de nombres: POST /v1/origin/app/installations/{installationId}/user_access_tokens. Requiere un JWT de aplicación y una instalación a la que se haya concedido namespace:user_tokens:write. Indica el usuario con userId o userEmail; los campos opcionales scopes y repositoryIds restringen el acceso. El token caduca como máximo a los 15 minutos y nunca después que el JWT de aplicación.
• Añadido. Los actores de usuario pueden incluir performedVia.app con el id de la aplicación y un displayName opcional cuando una aplicación ha actuado en nombre del usuario. El campo no aparece en las acciones directas del usuario y puede faltar cuando no hay datos de delegación disponibles. Consulta Actuar en nombre de usuarios.
• Añadido. List Commits acepta los filtros authorEmails y committerEmails, con hasta 100 correos electrónicos distintos cada uno. La coincidencia no distingue entre mayúsculas y minúsculas e ignora los espacios iniciales y finales; si se establecen ambas listas, un commit debe coincidir con las dos. Una página filtrada puede estar vacía y aun así incluir un nextPageToken, así que sigue paginando hasta que el token esté vacío.
• Cambiado. Una ejecución de comprobación cancelada ya no sustituye a un resultado satisfactorio. Una publicación completed con la conclusión cancelled sobre una ejecución que está completed con success, neutral o skipped se ignora por obsoleta, sea cual sea su externalUpdatedAt, por lo que Post Check Run y Batch Upsert Check Runs responden 200 con la ejecución almacenada y el outcome ignored_stale. Si la cancelación se publica como un nuevo intento de ejecución o de suite, queda clasificada por debajo del intento satisfactorio, por lo que List Check Runs For Commit, List Check Suites For Commit, List Check Runs For Suite y Get Pull Request Mergeability siguen informando del resultado satisfactorio. Un fallo más reciente sigue reemplazando a un resultado satisfactorio, y una cancelación sigue prevaleciendo sobre una ejecución fallida o pendiente; consulta la regla completa en Attempts and the current attempt.

• Añadido. List Namespaces lista los espacios de nombres en los que puedes listar repositorios, ordenados por slug: GET /v1/origin/namespaces. Los candidatos son los espacios de nombres de tus equipos, tu espacio de nombres personal y los espacios de nombres que contienen repositorios a los que se te ha concedido acceso. Solo se devuelven aquellos en los que tienes namespace:repositories:read, de modo que cada namespace.slug es un ownerSlug válido para List Repos. El campo viewerCanCreateRepositories de cada entrada indica si una llamada a Crear repositorio en ese espacio de nombres superaría, en tu caso, la autorización y las comprobaciones del plan y los ajustes del propietario. Las páginas contienen 30 espacios de nombres de forma predeterminada y 100 como máximo. Requiere una credencial de usuario de Cherri Code, no necesita ningún scope y cuesta 1 punto; los tokens de aplicación, los tokens de acceso de instalación y las cuentas de servicio reciben PermissionDenied (HTTP 403).

• Cambiado. Al reabrir una pull request mediante Update Pull Request, se registra una nueva version si la cabecera se movió mientras la pull request estaba cerrada, y se envía pull_request.head_ref.pushed. Antes, la pull request conservaba la cabecera que tenía al cerrarse hasta que se volvía a hacer push a la rama. La versión registrada incluye sus propios headSha, baseSha y estadísticas del diff, con la misma estructura que registra un push. Las pull requests fusionadas no se ven afectadas.
• Cambiado. Un SHA de commit abreviado enviado a Get Commit o List Commit Files se resuelve igual que en Get Git Commit: solo entre objetos commit, de modo que un prefijo que identifica un único commit se resuelve aunque lo comparta un blob o un tree del repositorio. La entrada del 22 de septiembre solo mencionaba Get Git Commit. Get Blob y Get Tag no cambian.

Aplicaciones e instalaciones

• Cambio. Crear token de acceso de instalación indica que un token caduca como máximo a los 15 minutos y nunca después que el JWT de aplicación que lo solicitó. Lee expiresAt en la respuesta y emite un token nuevo cuando venza, en lugar de dar por hecha una duración.

Pull requests

• Cambio incompatible. Create Pull Request ya no acepta parentPullNumber. Una solicitud que lo incluya devuelve InvalidArgument (HTTP 400) indicando parent_pull_number en lugar de crear la pull request, de modo que un cliente de red que siga enviándolo falla de forma explícita en vez de perder sin aviso el padre de la pila. Migración: envía parentPullRequest con un miembro number en todos los lugares donde tu integración enviaba parentPullNumber.
• Añadido. Delete Pull Request Comment elimina un comentario de pull request a partir de su id de Origin: DELETE /v1/origin/repos/{ownerSlug}/{repoName}/pulls/comments/{commentId}. El autor del comentario siempre puede eliminarlo; cualquier otro llamador debe tener acceso de escritura al repositorio mediante repository:contents:write o recibirá PermissionDenied (HTTP 403). Al eliminar el último comentario de un hilo, se elimina también el hilo; al eliminar cualquier otro comentario, el hilo se conserva. En ambos casos, las reacciones y el historial de ediciones del comentario se eliminan con él. Un id desconocido o ya eliminado devuelve 404. Requiere repository:pull_requests:reviews:write y cuesta 5 puntos.
• Añadido. Las respuestas de pull request incluyen un objeto stack con el id de la pila y la parentPullRequest sobre la que está apilada esta pull request. El objeto se omite cuando la pull request no forma parte de una pila, y en la raíz no incluye parentPullRequest. Lo devuelven List Pull Requests, Get Pull Request, Create Pull Request, Update Pull Request y Merge Pull Request, y se incluye en todos los payloads pull_request.*. Un stack entregado refleja la topología en el momento del evento que lo incluía.
• Añadido. Create Pull Request y Update Pull Request aceptan parentPullRequest, un selector que indica el padre de la pila por number o id, o que lo elimina con clear al actualizar. Debe establecerse exactamente un miembro; un selector vacío, clear: false, más de un miembro o clear al crear devuelven InvalidArgument (HTTP 400). La edición es solo una asociación: no se reescribe ninguna rama y base solo se redirige si también se envía. Update la aplica después de base, por lo que un padre explícito prevalece sobre el que se derive de un cambio de base.
• Añadido. List Pull Requests acepta stackId, un id de pila tal como se devuelve en stack.id. Devuelve los miembros de esa pila en el orden de clasificación solicitado, no en el orden de la pila, así que reconstruye la pila a partir del stack.parentPullRequest de cada miembro. state sigue teniendo open como valor predeterminado, así que pasa state=all para obtener la pila completa. Un id bien formado que no corresponda a ninguna pila del repositorio devuelve una lista vacía; cualquier otro valor devuelve InvalidArgument (HTTP 400).
• Añadido. List Pull Requests acepta headSha, el SHA hexadecimal completo de 40 o 64 caracteres de la cabecera de una pull request. Selecciona una pull request si alguna de sus versiones registradas tiene ese commit de cabecera, ya sea actual o reemplazada, así que compara head.sha en cada resultado para distinguir ambos casos. Los SHA mal formados, abreviados o desconocidos no devuelven ninguna coincidencia.

Ejecuciones de comprobación

• En desuso. checkRuns en la respuesta de Batch Upsert Check Runs queda en desuso en favor de results[].checkRun y se eliminará en una versión futura. Sigue incluyendo las mismas ejecuciones en el mismo orden. Migración: lee results[].checkRun, que asocia cada ejecución almacenada con el outcome de su escritura.
• Añadido. Post Check Run devuelve outcome y Batch Upsert Check Runs devuelve results[], con un elemento por cada ejecución publicada en el orden de la solicitud, y cada uno asocia checkRun con su propio outcome. El valor es created, updated, unchanged o ignored_stale. Una publicación cuyo externalUpdatedAt sea anterior a la marca de tiempo almacenada se ignora, y una publicación que repite los valores almacenados no cambia nada; en ambos casos se responde 200 con la ejecución almacenada y updatedAt no se modifica, por lo que outcome es la única forma de distinguirlas.
• Cambiado. El message de una anotación de ejecución de comprobación puede contener Markdown, que Origin renderiza en la página del pull request, tanto en la pestaña Checks como en la tarjeta inline de Changes. Se acepta en Post Check Run y Batch Upsert Check Runs, y Get Check Run lo devuelve. rawDetails sigue siendo texto sin formato.

Datos de Git

• Cambio. Get Git Commit resuelve un sha abreviado solo si tiene al menos 5 caracteres hexadecimales, y solo entre objetos commit; la solicitud falla si ningún commit o más de un commit coincide con la abreviatura. Los SHA completos, las ramas, los tags y HEAD se resuelven igual que antes.

Autoridades de certificación SSH

• Añadido. List SSH Certificate Authorities enumera las autoridades de certificación SSH en las que confía un propietario para git sobre SSH, de la más reciente a la más antigua, junto con requireCertificates, que indica si el propietario exige certificados: GET /v1/origin/owners/{ownerSlug}/ssh-certificate-authorities. La respuesta no está paginada y cada entrada de certificateAuthorities[] incluye id, name, keyType, fingerprint, publicKey y createdAt. Requiere namespace:settings:read.
• Añadido. Add SSH Certificate Authority añade una autoridad en la que confía el propietario y la devuelve: POST /v1/origin/owners/{ownerSlug}/ssh-certificate-authorities. El cuerpo acepta un publicKey obligatorio, que debe ser una línea de authorized_keys de OpenSSH cuyo tipo de clave sea ssh-ed25519, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521 o ssh-rsa con un módulo de al menos 2048 bits, y un name obligatorio de 255 caracteres como máximo. Un certificado, un tipo de clave no compatible o una clave RSA más corta devuelve InvalidArgument (HTTP 400); una clave que el propietario ya tiene registrada devuelve AlreadyExists (HTTP 409 Conflict), ya que la comprobación se limita al propietario y no abarca todo Origin; y un propietario que no sea propiedad de un equipo devuelve FailedPrecondition (HTTP 400). Requiere una credencial de usuario de Cherri Code con namespace:settings:write.
• Añadido. Delete SSH Certificate Authority elimina una autoridad del propietario y responde con 204 No Content: DELETE /v1/origin/owners/{ownerSlug}/ssh-certificate-authorities/{certificateAuthorityId}. Todos los certificados firmados por la autoridad dejan de funcionar y, mientras el propietario exija certificados, no se puede eliminar su última autoridad; si se intenta, se devuelve FailedPrecondition (HTTP 400). Requiere una credencial de usuario de Cherri Code con namespace:settings:write.
• Añadido. Set SSH Certificate Requirement establece si el propietario exige certificados SSH: POST /v1/origin/owners/{ownerSlug}/ssh-certificate-authorities:setRequirement. El cuerpo acepta un booleano requireCertificates obligatorio y la respuesta incluye el ajuste requireCertificates del propietario. Mientras esté activado, git sobre SSH en los repositorios del propietario solo acepta certificados de sus autoridades, por lo que se rechazan las claves SSH registradas por los usuarios y las claves de API de usuario a través de HTTPS. Exigir certificados sin ninguna autoridad registrada devuelve FailedPrecondition (HTTP 400), y establecer el valor actual se completa correctamente sin aplicar ningún cambio. Requiere una credencial de usuario de Cherri Code con namespace:settings:write.

Webhooks

• Añadido. pull_request.comment.reaction.added y pull_request.comment.reaction.removed son eventos de webhook a los que puedes suscribirte y se entregan cuando se añade o se elimina una reacción en un comentario de pull request. Su payload compartido incluye la referencia pullRequest, una referencia comment con su thread y la reaction con su content y su reactor. Un evento de adición se entrega al menos una vez: si el reactor vuelve a añadir una reacción que ya tiene, el evento se entrega de nuevo para el mismo comentario, reactor y contenido, así que deduplica según esa terna. Si el reactor elimina una reacción que no tiene, no se entrega nada.
• Cambiado. El payload de pull_request.label.removed incluye actor, el principal que eliminó la etiqueta, cuando se conoce. La entrada del 19 de septiembre indicaba que actor solo se establecía en pull_request.label.added, pero se establece en ambos eventos cuando se conoce el principal.

• Añadido. Delete Git Ref elimina una referencia de rama: DELETE /v1/origin/repos/{ownerSlug}/{repoName}/git/refs/{ref}. La ruta indica la rama como refs/heads/<branch> o heads/<branch>, y solo se pueden eliminar referencias de rama. Si la rama no existe, devuelve 404. La rama predeterminada del repositorio, una rama protegida por una regla de eliminación y un repositorio cuyo contenido se replica desde otro host devuelven FailedPrecondition (HTTP 400). Si la punta de la rama se mueve mientras la eliminación está en curso, devuelve FailedPrecondition (HTTP 400) o Aborted (HTTP 409 Conflict); en ese caso, vuelve a intentar eliminar la nueva punta. Los pull requests cuya cabecera es la rama eliminada se cierran, igual que cuando se elimina la rama mediante push. Requiere repository:contents:write y tiene un coste de 5 puntos.
• Añadido. pull_request.label.added y pull_request.label.removed son eventos de webhook a los que puedes suscribirte. Se envían cuando se asigna una etiqueta a un pull request o se retira de él. Su payload compartido incluye la referencia pullRequest y la instantánea label. Solo en pull_request.label.added incluye además un actor que identifica al principal que asignó la etiqueta. Al eliminar la definición de una etiqueta, se envía un pull_request.label.removed por cada pull request que tenía esa etiqueta.

• Cambio incompatible. Crear aplicación exige que el propietario del espacio de nombres cumpla los requisitos para escribir en Origin, la misma condición previa que Crear repositorio siempre ha exigido. Una solicitud sobre un espacio de nombres cuyo propietario sea un usuario sin un plan Pro, Pro Student, Pro+, Ultra o Start, o un equipo sin un plan de equipo de pago activo, con modo de privacidad (heredado) o con Origin desactivado por un administrador de equipo, ahora devuelve FailedPrecondition (HTTP 400) en lugar de crear la aplicación. La comprobación evalúa los requisitos del propietario del espacio de nombres, no los del usuario que realiza la llamada. Migración: crea aplicaciones solo en espacios de nombres cuyo propietario pueda escribir en Origin y gestiona FailedPrecondition en cualquier punto donde tu integración daba por hecho que la aplicación se había creado.
• Cambiado. Origin concede a un receptor de webhooks 10 segundos para responder a una entrega, en lugar de los cinco segundos anteriores. El plazo abarca la resolución DNS, la conexión, el protocolo de enlace TLS y el tiempo hasta la respuesta, y se aplica a cada intento. Si un intento lo supera, se considera un error de transporte y se reintenta según la programación descrita en Reintentos.

• Cambio incompatible. Los archivos de Get Repo Tarball envuelven el árbol del repositorio en un único directorio de nivel superior llamado {ownerSlug}-{repoName}-{shortSha}/, donde shortSha son los primeros 7 caracteres hexadecimales del commit resuelto, igual que en la estructura del endpoint de tarball de GitHub. Antes, las entradas del archivo estaban en la raíz del tar, sin directorio envolvente. Migración: elimina un componente inicial de la ruta al extraer (por ejemplo, con tar --strip-components=1) allí donde tu integración leyera entradas desde la raíz del tar.
• Cambio incompatible. Get App requiere namespace:apps:read en el espacio de nombres propietario de la aplicación en lugar de app:settings:read, el scope anunciado junto con el endpoint en la entrada del 12 de septiembre. app:settings:read ya no autoriza nada y se ha eliminado del catálogo de scopes; app:settings:write no cambia y sigue cubriendo Update App, Add App Signing Key y Revoke App Signing Key. Migración: usa namespace:apps:read en el espacio de nombres propietario de la aplicación allí donde tu integración usara app:settings:read.
• Añadido. Listar repositorios de la instalación de la aplicación acepta filter, una búsqueda de subcadena que no distingue entre mayúsculas y minúsculas y se aplica a los nombres de repositorio y a los espacios de nombres del propietario. Un valor owner/repo con una sola barra compara cada mitad con su campo correspondiente, se ignoran los espacios en blanco iniciales y finales, y un valor vacío no aplica ningún filtro. Cada token de página conserva el filtro con el que se generó, así que envía el mismo filtro al solicitar las páginas siguientes.
• Modificado. La especificación de OpenAPI ya no añade format: enum a los esquemas de enumeración de tipo cadena. Esa clave no es un formato registrado de OpenAPI ni de JSON Schema, duplicaba la lista enum que la acompaña y los generadores que la asignaban a un tipo con nombre producían código que no compila. Los nombres de los esquemas, los valores de enumeración y el JSON transmitido no cambian; vuelve a generar cualquier cliente de red creado a partir de la especificación para obtener los tipos corregidos.

• Cambio incompatible. Los payloads de repository.check_run.created y repository.check_run.completed ya no incluyen un actor en el nivel del payload. Este campo repetía el principal de la suite de comprobaciones propietaria, que el mismo payload ya entrega como checkSuite.actor y checkRun.actor. Migración: lee checkRun.actor, que siempre coincide con el actor de la suite propietaria, en todos los lugares donde tu integración leía el actor de nivel superior del payload.
• Cambio incompatible. caseInsensitive y wholeWord en Grep Contents solo se aplican cuando literal es true. Una búsqueda con expresión regular ahora ignora ambos booleanos, que antes respetaba, y un query que solo contiene (?i) devuelve InvalidArgument (HTTP 400). Migración: establece literal para seguir usando los booleanos o, en una búsqueda con expresión regular, escribe en su lugar un (?i) inicial y límites de palabra \b en query.
• Cambio incompatible. La especificación de OpenAPI cambia el nombre del esquema de componente Thread a CommentThread. Es el esquema de respuesta de Update Pull Request Thread y el tipo del objeto thread en un comentario de pull request. Los nombres de campos, las rutas, los IDs de operación y el JSON transmitido no cambian, así que una integración que lee las respuestas directamente no necesita ningún cambio. Migración: vuelve a generar cualquier cliente creado a partir de la especificación y cambia el nombre del tipo allí donde el código generado usaba Thread.
• Añadido. Add App Installation Repositories añade repositorios a la selección de una instalación existente y devuelve la instalación actualizada: POST /v1/origin/namespaces/{namespaceSlug}/installations/{installationId}/repos. El cuerpo acepta un array obligatorio repoIds, que se une a la selección actual; la escritura nunca modifica los scopes de la instalación, y una solicitud cuyos repositorios ya tienen grant se completa correctamente sin cambiar nada. Un repositorio fuera del espacio de nombres, una instalación que ya cubre todos los repositorios del espacio de nombres, una instalación suspendida y una anterior a los scopes por instalación devuelven FailedPrecondition (HTTP 400) y no conceden nada. Requiere una credencial de usuario de Cherri Code con namespace:installations:write y cuesta 5 puntos. La primera instalación sigue requiriendo el consentimiento de un administrador del espacio de nombres en el navegador.
• Añadido. Las respuestas con cargo de Git sobre HTTPS incluyen X-RateLimit-Limit, X-RateLimit-Remaining y X-RateLimit-Used, con X-RateLimit-Resource establecido en git. Git contabiliza un presupuesto propio, independiente del presupuesto REST que Límites de tasa documenta como core. Una solicitud de Git que supera el presupuesto devuelve 429 con Retry-After y X-RateLimit-Reset, y una solicitud no contabilizada no incluye encabezados de límite de tasa.
• Modificado. Upsert Repository Grant y Upsert Namespace Grant aceptan un principal group que pertenezca al propio equipo del propietario del recurso, además de los grupos de la organización que ya aceptaban. Los grupos propios de un equipo pueden recibir grants aunque ese equipo no esté vinculado a una organización, mientras que un grupo que pertenece a otro equipo sigue devolviendo FailedPrecondition (HTTP 400). La página Grants describe los tipos de principal.

• Cambio incompatible. Create Repo requiere namespace:repositories:create en lugar de namespace:new_repository:write, que ya no autoriza nada y se ha eliminado del catálogo de scopes. Migración: solicita namespace:repositories:create en la credencial de usuario de Cherri Code allí donde tu integración solicitaba namespace:new_repository:write.
• Añadido. Get Pull Request Mergeability indica si un pull request se puede fusionar y, si no es posible, devuelve las condiciones tipadas que lo bloquean: GET /v1/origin/repos/{ownerSlug}/{repoName}/pulls/{pullNumber}/mergeability. verdict es mergeable o blocked, y cada entrada de blockers incluye un kind, un message legible y el pull request de evaluatedPullRequests al que pertenece, de modo que el veredicto de un pull request apilado abarca todos los pull requests desde la raíz de la pila hasta él. La protección opcional expectedHeadSha devuelve Aborted (HTTP 409 Conflict) si la cabecera ha cambiado, y un repositorio espejo o una pila de más de 200 pull requests devuelve FailedPrecondition (HTTP 400). La operación se publica en vista previa, marcada como x-cursor-visibility: PREVIEW en la especificación de OpenAPI, así que decodifica sus respuestas tolerando campos y valores de enumeración desconocidos, y trata cualquier verdict no reconocido como blocked. Requiere repository:pull_requests:read y cuesta 10 puntos.
• Añadido. Grep Contents busca en el texto de los archivos de un repositorio en una referencia determinada y devuelve las líneas coincidentes: POST /v1/origin/repos/{ownerSlug}/{repoName}:grep. El cuerpo acepta un query obligatorio, que se interpreta como expresión regular salvo que se establezca literal, además de ref, caseInsensitive, wholeWord, contextBefore y contextAfter (los valores superiores a 10 se reducen a 10), filterPath, las listas de patrones glob includes y excludes (20 entradas como máximo cada una) y maxResults (valor predeterminado y máximo: 1000). Cada entrada devuelta corresponde a una línea, y la respuesta solo está completa cuando limitHit es false; no hay paginación. Requiere repository:contents:read y cuesta 5 puntos.
• Añadido. El status de las ejecuciones de comprobación tiene un cuarto valor, rerequested, y List Check Runs For Commit lo acepta como filtro de status. Indica una ejecución completada cuya reejecución se ha solicitado y a la que la aplicación propietaria aún no ha respondido, así que trátala como pendiente y muéstrala igual que queued. Aparece en Get Check Run, List Check Runs For Suite, List Check Runs For Commit y Rerequest Check Run. Solo Origin puede establecerlo: una solicitud de Post Check Run o Batch Upsert Check Runs que lo incluya devuelve InvalidArgument (HTTP 400).
• Añadido. List Pull Requests acepta sortBy, con los valores created (orden de creación, el predeterminado) o updated (fecha de la última actualización). direction ordena según sortBy y sigue teniendo desc como valor predeterminado. Además, cada token de página conserva la ordenación con la que se generó, por lo que se rechaza cualquier token reutilizado con la otra ordenación.
• Añadido. List Pull Requests acepta state=merged, que muestra solo los pull requests fusionados. closed sigue abarcando todos los pull requests que ya no están abiertos, incluidos los fusionados, por lo que los clientes existentes siguen obteniendo los mismos resultados.
• Cambiado. Rerequest Check Run establece el status de la ejecución en rerequested, lo que sustituye a la nota del 11 de septiembre que indicaba que la llamada nunca cambia el status ni la conclusion de la propia ejecución. La conclusion y los tiempos de la ejecución siguen describiendo el intento sustituido, así que lee conclusion solo cuando status sea completed. La ejecución sigue apareciendo como pendiente en List Check Runs For Suite y List Check Runs For Commit hasta que responda la aplicación propietaria, lo que además borra rerequestedAt y guarda el estado publicado.
• Cambiado. El payload de repository.check_run.rerequested incluye checkRun.status como rerequested en lugar de completed, mientras que checkRun.conclusion y los tiempos siguen describiendo el intento sustituido. La migración es la misma que para el endpoint: ramifica la lógica según checkRun.status y lee checkRun.conclusion solo cuando sea completed.

Pull requests

• Cambio incompatible. Create Pull Request y Update Pull Request rechazan un base que no corresponda a una rama existente. Si se indica un SHA de commit, un nombre de tag o una rama inexistente, se devuelve InvalidArgument (HTTP 400) junto con la referencia completa que Origin buscó; antes, la misma solicitud creaba el pull request o cambiaba su rama de destino. En un pull request así nunca se podía preparar la referencia de fusión, por lo que CI nunca la recibía y el pull request no se podía fusionar. Migración: pasa un nombre de rama, en forma corta (main) o completa (refs/heads/main), y cambia la rama de destino de cualquier pull request existente cuya base sea un SHA de commit o un tag.

Aplicaciones

• Añadido. Crear aplicación registra una aplicación propiedad de un espacio de nombres: POST /v1/origin/namespaces/{namespaceSlug}/apps. El cuerpo acepta los campos obligatorios displayName y publicKey (la clave pública Ed25519 en formato PEM SPKI con la que la aplicación firma sus JWT), además de los opcionales webhookUrl, events, description, websiteUrl, installationRedirectUris y defaultScopes. Las aplicaciones se crean como privadas, y una URL de webhook, un tipo de evento, un URI de redirección o un scope no válidos devuelven InvalidArgument (HTTP 400). Requiere namespace:apps:create en una credencial de usuario de Cherri Code y cuesta 10 puntos.
• Añadido. List Namespace Apps enumera las aplicaciones de un espacio de nombres, de la más reciente a la más antigua: GET /v1/origin/namespaces/{namespaceSlug}/apps. Las entradas solo incluyen metadatos de visualización (id, displayName y description); para consultar la configuración de webhook de una aplicación, usa Get App. Requiere namespace:apps:read y cuesta 1 punto.
• Añadido. Get App devuelve la configuración completa de una aplicación a partir de su id: GET /v1/origin/apps/{appId}. Es la operación de lectura que usa el publicador para gestionar la aplicación; Get Authenticated App sigue siendo la operación con la que una aplicación consulta sus propios datos mediante su JWT. Requiere app:settings:read y cuesta 1 punto.
• Añadido. Update App modifica los ajustes de una aplicación: PATCH /v1/origin/apps/{appId}. displayName, webhookUrl, description y websiteUrl son campos simples, mientras que events, installationRedirectUris y defaultScopes son contenedores que reemplazan la lista completa. Los campos omitidos no se modifican, una solicitud que no establece ningún valor devuelve InvalidArgument (HTTP 400), y enviar webhookUrl como cadena vacía desactiva la entrega y cancela definitivamente las entregas pendientes de la aplicación. Requiere app:settings:write y cuesta 5 puntos.
• Añadido. Add App Signing Key registra una clave pública Ed25519 adicional para una aplicación: POST /v1/origin/apps/{appId}/signing_keys. La respuesta incluye el kid que debe usarse como ID de clave del JWT, es decir, el resumen SHA-256 codificado en base64url de la codificación SPKI DER de la clave. Registrar una clave ya existente devuelve AlreadyExists (HTTP 409 Conflict), y superar el límite de claves activas de la aplicación devuelve FailedPrecondition (HTTP 400). Requiere app:settings:write y cuesta 5 puntos.
• Añadido. Revoke App Signing Key retira una clave de firma de la app y responde con 204 No Content: DELETE /v1/origin/apps/{appId}/signing_keys/{kid}. Los JWT de aplicación firmados con la clave revocada dejan de autenticarse, y revocar la última clave activa devuelve FailedPrecondition (HTTP 400). Requiere app:settings:write y cuesta 5 puntos.
• Añadido. Las respuestas de aplicación incluyen namespaceSlug, el slug del espacio de nombres propietario de la aplicación, además de description, websiteUrl y defaultScopes. Estos campos los devuelven Get Authenticated App, Get App, Crear aplicación y Update App.

Grants

• Añadido. List Repository Grants enumera los usuarios, grupos y grupos del equipo propietario que tienen un permiso concedido directamente sobre un repositorio: GET /v1/origin/repos/{ownerSlug}/{repoName}/grants. No se incluyen los permisos heredados del propietario del repositorio, y se omite cualquier principal que ya no se pueda resolver, por lo que una página puede contener menos grants que pageSize. Requiere repository:settings:read y cuesta 1 punto.
• Añadido. Upsert Repository Grant establece el permiso que un principal tiene directamente sobre un repositorio: POST /v1/origin/repos/{ownerSlug}/{repoName}/grants. El cuerpo indica exactamente uno de user, group o teamGroup, y un permission con valor read, write o admin; custom devuelve InvalidArgument (HTTP 400), y un principal ajeno al equipo u organización del propietario devuelve FailedPrecondition (HTTP 400). Repetir un grant que el principal ya tiene se completa correctamente sin cambios. Requiere repository:settings:write y cuesta 5 puntos.
• Añadido. Delete Repository Grant elimina el permiso que un principal tiene directamente sobre un repositorio y responde 204 No Content: DELETE /v1/origin/repos/{ownerSlug}/{repoName}/grants. Los permisos heredados del propietario no se ven afectados, por lo que un grupo del equipo propietario vuelve a su valor predeterminado a nivel de propietario, y eliminar un permiso que el principal no tiene directamente se completa correctamente sin cambios. Requiere repository:settings:write y cuesta 5 puntos.
• Añadido. List Namespace Grants enumera a quién se le ha concedido acceso a un propietario: GET /v1/origin/owners/{ownerSlug}/grants. Cada grant incluye el permiso que otorga sobre todos los repositorios del propietario; los grants de admin aparecen primero y se excluyen los concedidos sobre repositorios individuales. Requiere namespace:settings:read y cuesta 1 punto.
• Añadido. Upsert Namespace Grant establece el permiso que un principal tiene directamente sobre un propietario: POST /v1/origin/owners/{ownerSlug}/grants. permission admite PERMISSION_READ, PERMISSION_CONTRIBUTOR, PERMISSION_WRITE o PERMISSION_ADMIN, y PERMISSION_CUSTOM devuelve InvalidArgument (HTTP 400). Un principal ajeno al equipo propietario o a su organización, o una escritura que dejaría al propietario sin admin, devuelve FailedPrecondition (HTTP 400). Requiere namespace:settings:write y cuesta 5 puntos.
• Añadido. Delete Namespace Grant elimina el permiso que un principal tiene directamente sobre un propietario y responde 204 No Content: DELETE /v1/origin/owners/{ownerSlug}/grants. Los grants por repositorio no se ven afectados, y una eliminación que dejaría al propietario sin admin devuelve FailedPrecondition (HTTP 400). Requiere namespace:settings:write y cuesta 5 puntos.

Instalaciones

• Añadido. Las instalaciones incluyen suspendedAt, que se establece mientras la instalación está suspendida y se omite mientras está activa, y deletedAt, que solo aparece en la instantánea del webhook installation.deleted. Ambos campos los devuelven Get App Installation y List App Installations.
• Añadido. Los cinco payloads installation.* incluyen installation.appId, con el mismo valor que el app.id del propio payload, e installation.updatedAt en installation.created e installation.updated. Todos los campos de una instalación que devuelve Get App Installation están presentes en la instantánea con el mismo nombre y tipo, por lo que un mismo decodificador sirve para leer ambos.

Ejecuciones de comprobación

• Cambio incompatible. El payload de repository.check_run.rerequested ya no incluye un campo rerequestedBy de nivel superior. El principal que solicitó la nueva ejecución figura ahora en la ejecución de comprobación incrustada como checkRun.rerequestedBy, lo que sustituye la nota del 10 de septiembre según la cual el payload incluía al solicitante junto al repositorio, la suite y la ejecución. Migración: lee checkRun.rerequestedBy allí donde tu receptor leía el campo rerequestedBy propio del payload.
• Añadido. Rerequest Check Run pide a la aplicación que informó de una ejecución de comprobación que la vuelva a ejecutar: POST /v1/origin/repos/{ownerSlug}/{repoName}/check-runs/{checkRunId}/rerequest con un cuerpo vacío. La ejecución debe estar en estado completed, debe incluir isRerequestable, debe ser el intento actual para su key y debe estar en la cabecera actual de una pull request abierta; en cualquier otro caso se devuelve FailedPrecondition (HTTP 400), y una segunda solicitud mientras haya otra pendiente devuelve AlreadyExists (HTTP 409 Conflict). La llamada nunca modifica el status ni la conclusion de la propia ejecución. Cualquier principal con repository:contents:write puede volver a solicitar cualquier ejecución que lo admita, sea cual sea la aplicación que la haya informado, y la llamada tiene un coste de 5 puntos.
• Añadido. Las ejecuciones de comprobación incluyen rerequestedBy, el principal que solicitó la nueva ejecución, presente siempre que rerequestedAt esté establecido y que se borra junto con él. Lo devuelven Get Check Run, List Check Runs For Suite, List Check Runs For Commit, Post Check Run, Batch Upsert Check Runs y Rerequest Check Run.
• Modificado. rerequestedAt indica una nueva solicitud pendiente, no una marca de tiempo única. Origin lo borra cuando la aplicación propietaria responde publicando una ejecución nueva para el mismo head SHA y key, ya sea una nueva ejecución con un nuevo externalId o una actualización de la ejecución solicitada con el mismo, tras lo cual la ejecución puede volver a solicitarse. Esto sustituye la nota del 10 de septiembre según la cual una ejecución de comprobación se vuelve a solicitar como máximo una vez, por lo que un receptor puede recibir más de un evento repository.check_run.rerequested para la misma ejecución; sigue deduplicando los reenvíos por el id del evento.
• Modificado. Una ejecución de comprobación solicitada de nuevo permanece en List Check Runs For Suite y List Check Runs For Commit y aparece como pendiente, con rerequestedAt establecido y sin cambios en su status y conclusion ya obsoletos, en lugar de desaparecer de ambos listados hasta que la aplicación responda. Una comprobación obligatoria bloquea la fusión como comprobación pendiente, no como comprobación ausente. Esto sustituye la nota del 10 de septiembre según la cual la ejecución desaparece hasta que llega un nuevo intento.

Repositorios

• Añadido. Update Repo modifica los ajustes del repositorio: PATCH /v1/origin/repos/{ownerSlug}/{repoName}. El cuerpo admite los campos opcionales defaultBranch, allowMergeCommit, allowSquashMerge, deleteBranchOnMerge y visibility, y los campos omitidos no se modifican. allowMergeCommit y allowSquashMerge deben enviarse juntos y al menos uno de ellos debe ser true; defaultBranch y deleteBranchOnMerge devuelven FailedPrecondition (HTTP 400) en un repositorio que se sincroniza desde un origen; y una solicitud que no establece nada devuelve InvalidArgument (HTTP 400). Los grupos se aplican en un orden fijo y no de forma atómica, por lo que, si se rechaza un grupo, los anteriores quedan aplicados. Requiere repository:settings:write y cuesta 5 puntos.
• Añadido. Transition Repo Mirror inicia un cambio de dirección de la réplica y devuelve el job que lo supervisa: POST /v1/origin/repos/{ownerSlug}/{repoName}/mirror:transition. El cuerpo requiere un transition con el valor initial_to_inbound, inbound_to_outbound o outbound_to_inbound, y el repositorio mantiene un estado de réplica en transición mientras se ejecuta el job. Si el repositorio no se encuentra en el estado inicial que espera la transición, o ya tiene un job activo, se devuelve FailedPrecondition (HTTP 400). Requiere repository:mirror:write en una credencial de usuario de Cherri Code que también administre el repositorio en el origen de la réplica, y cuesta 10 puntos.
• Añadido. Force Repo Mirror Cutover migra un repositorio a su origen sin enviarle de vuelta el estado divergente: POST /v1/origin/repos/{ownerSlug}/{repoName}/mirror:forceCutover con un cuerpo vacío. El origen se adopta tal cual como fuente de verdad, y las refs que solo existen en Origin se guardan en una instantánea y se descartan. Solo se acepta para un repositorio con estado outbound, o uno bloqueado en una transición de outbound a inbound cuyo job activo indique requires_attention, en cuyo caso la migración forzada lo sustituye. Requiere repository:mirror:write y cuesta 10 puntos.
• Añadido. Detach Repo Mirror desvincula permanentemente un repositorio replicado de su origen y responde 204 No Content: DELETE /v1/origin/repos/{ownerSlug}/{repoName}/mirror. El repositorio conserva su contenido y pasa a ser un repositorio nativo, la sincronización se detiene en ambas direcciones y se elimina la credencial de despliegue de la réplica. Desvincular un repositorio ya desvinculado se completa correctamente sin ningún efecto, mientras que un repositorio que nunca tuvo réplica devuelve FailedPrecondition (HTTP 400). Requiere repository:mirror:delete y cuesta 5 puntos.
• Añadido. Get Mirror Transition Job devuelve un job de transición por id: GET /v1/origin/repos/{ownerSlug}/{repoName}/mirror/transition-jobs/{jobId}. Un job indica su transition, un status con valor queued, running, succeeded, failed_rolled_back, requires_attention o superseded, un attemptCount y, si ha fallado, lastErrorCode y lastErrorMessage. Su cadena phase es un detalle meramente informativo que irá incorporando nuevos valores a medida que evolucione el proceso de transición, así que consulta periódicamente status para detectar la finalización en lugar de comparar phase. Requiere repository:metadata:read y cuesta 1 punto.
• Añadido. Get Active Mirror Transition Job devuelve el job de transición en curso del repositorio y el último finalizado: GET /v1/origin/repos/{ownerSlug}/{repoName}/mirror/transition-jobs:active. Tanto activeJob como lastJob son opcionales, por lo que un repositorio que nunca ha realizado una transición devuelve un objeto vacío; para distinguir una transición que terminó de una que nunca se ejecutó, consulta periódicamente hasta que activeJob desaparezca y luego lee lastJob. Requiere repository:metadata:read y cuesta 1 punto.
• Cambiado. Las referencias de los endpoints de estado de réplica se han trasladado a la API de migración de Origin. Sus contratos HTTP no han cambiado, y los anclajes anteriores de la API de Origin enlazan a la nueva referencia.

• Añadido. Merge Pull Request acepta un mergeMethod opcional con valor merge o squash, que determina si la pull request se integra como un commit de fusión o como un único commit combinado (squash). Un método que el repositorio no permite se rechaza con FailedPrecondition (HTTP 400), y cualquier otro valor, incluido rebase, con InvalidArgument (HTTP 400). Omítelo para mantener el comportamiento anterior: un commit de fusión si el repositorio lo permite; si no, un squash, y siempre un squash cuando la rama base requiere un historial lineal.
• Añadido. Los payloads de repositorio incluyen visibility, cuyo valor es internal o private, junto con los booleanos allowMergeCommit, allowSquashMerge y deleteBranchOnMerge. Los cuatro son de solo lectura y los devuelven Get Repo, Crear repositorio, List Repos y Listar repositorios de la instalación de la aplicación.
• Añadido. Las ejecuciones de comprobación incluyen isRerequestable, con el que la aplicación que las informa declara que la ejecución puede repetirse, y rerequestedAt, la marca de tiempo de la nueva solicitud. Envía isRerequestable en Post Check Run y Batch Upsert Check Runs; ambos campos se devuelven ahí y en Obtener ejecución de comprobación, List Check Runs For Suite y List Check Runs For Commit. Si declaras que una ejecución puede volver a solicitarse, tu aplicación se compromete a responder a cada nueva solicitud publicando una nueva ejecución para el mismo SHA de head y la misma key.
• Añadido. repository.check_run.rerequested se entrega cuando se vuelve a solicitar una ejecución de comprobación completada, y solo llega a la aplicación propietaria de la ejecución, no a todos los suscriptores del repositorio. Su payload incluye el repositorio, la suite de comprobación, la ejecución de comprobación marcada y rerequestedBy, pero no incluye contexto de pull request, así que obtén la pull request a partir de checkRun.sha. La suscripción requiere repository:checks:read. Una ejecución de comprobación solo puede volver a solicitarse una vez, así que descarta las entregas duplicadas usando el id del evento.
• Añadido. Cada esquema de payload de webhook de la especificación de OpenAPI incluye una extensión x-origin-webhook-events que indica los eventos con los que se entrega, además de un payload de ejemplo seleccionado como example del esquema. La nueva referencia de Payloads de eventos documenta los campos y el payload de ejemplo de cada payload, generados a partir de esos esquemas con la misma estructura que la referencia de endpoints.
• Cambiado. Una ejecución de comprobación que se vuelve a solicitar deja de aparecer en List Check Runs For Suite y List Check Runs For Commit hasta que la aplicación propietaria publique un nuevo intento o actualice el existente con un externalUpdatedAt más reciente. Por tanto, una comprobación obligatoria figura como ausente y bloquea la fusión mientras la nueva solicitud esté pendiente. Consulta la ejecución excluida por su propio id con Obtener ejecución de comprobación.

• Cambio incompatible. Un anclaje inline cuyo rango de líneas sobrepasa el final del archivo se rechaza con InvalidArgument (HTTP 400) en Create Pull Request Comment y Create Pull Request Review. El rango sigue sin limitarse a los fragmentos (hunks) del diff y se valida con el archivo tal como existe en el lado anclado: left lo lee en el commit base y right, en la cabecera. El error indica el número de líneas del archivo. En una revisión, basta un anclaje fuera de rango para que falle toda la solicitud y no se publique nada. Migración: antes de escribir, limita inline.startLine e inline.endLine al número de líneas del lado anclado. Si el anclaje queda fuera de los fragmentos del diff, obtén ese valor con Get Contents.

• Añadido. Create Git Ref crea una rama en un commit existente: POST /v1/origin/repos/{ownerSlug}/{repoName}/git/refs. Recibe ref como refs/heads/<branch> o heads/<branch> y sha como el SHA hexadecimal completo de un commit del repositorio; los tags y otros espacios de nombres de referencias devuelven InvalidArgument (HTTP 400). Si se crea una rama que ya apunta a sha, se devuelve la referencia existente, y si la rama ya existe en otro commit, se devuelve AlreadyExists (HTTP 409 Conflict). Requiere repository:contents:write y cuesta 5 puntos.
• Añadido. Create Commit From Files hace commit de cambios de archivos inline en una rama y la hace avanzar: POST /v1/origin/repos/{ownerSlug}/{repoName}/git/commits:createFromFiles. Cada entrada de files[] establece exactamente uno de estos campos: content (con encoding utf-8 o base64 y mode file, executable o symlink) o delete. Además, expectedHeadSha debe coincidir con la punta de la rama, que pasa a ser el padre del nuevo commit. La respuesta devuelve sha, treeSha y previousHeadSha. Cada solicitud admite como máximo 1000 cambios de archivos, 8 MiB por archivo y 32 MiB de contenido en total. Requiere repository:contents:write y cuesta 10 puntos.
• Cambiado. La entrega de webhooks reintenta un envío fallido siete veces en lugar de seis, y el primer reintento se produce 5 segundos después del fallo en lugar de 30. La secuencia completa es de 5 segundos, 30 segundos, 1 minuto, 2 minutos, 4 minutos y 8 minutos, por lo que un receptor que esté caído todo el tiempo recibirá un POST más en aproximadamente la misma ventana de 16 minutos. Deduplica el intento adicional por webhook-id, igual que haces con el resto.

• Cambio incompatible. Los metadatos de la aplicación ya no incluyen slug. Se ha eliminado de la respuesta de Get Authenticated App, de todos los actores de aplicación que devuelven las operaciones de checks, pull requests, revisiones y comentarios (actor.app, author.app y dismissal.dismissedBy.app), del objeto app de los cinco payloads de webhook installation.* y del payload de Ping Webhook. Esto sustituye a la nota del 2 de septiembre, según la cual los actores de aplicación incluían displayName junto con id y slug. Antes se garantizaba que un actor de aplicación incluyera slug; ahora incluye id y el campo opcional displayName. Migración: identifica las aplicaciones por id y etiquétalas con displayName en todos los puntos donde tu integración leía slug.
• Añadido. List Pull Request Comments acepta un parámetro de consulta opcional threadIds que limita el listado a los comentarios de esos hilos. Así puedes leer un solo hilo sin paginar todo el historial de comentarios de un pull request. Los duplicados se ignoran, por lo que el límite de 20 se aplica a IDs distintos; una lista más larga o un ID vacío devuelve InvalidArgument (HTTP 400). Los tokens de página incluyen el conjunto con el que se generaron, así que reinicia la paginación cuando cambie el filtro.
• Modificado. El filtro author de List Pull Requests ahora también acepta la dirección de correo electrónico exacta de un usuario, sin distinguir mayúsculas de minúsculas, además de los IDs de actor user_…, app_… y sa_… que ya admitía. Un correo electrónico que no corresponda a un único usuario devuelve una lista vacía en lugar de un error; antes, cualquier correo electrónico devolvía InvalidArgument (HTTP 400). Las aplicaciones y las cuentas de servicio no tienen una identidad de correo electrónico, así que de este modo solo se pueden seleccionar autores que sean usuarios. Los IDs de actor siguen siendo la identidad que devuelven estas respuestas.

• Añadido. List Check Runs For Commit acepta los parámetros de consulta opcionales checkName y status. checkName coincide exactamente con el name de una ejecución de comprobación, y status admite queued, in_progress o completed; cualquier otro valor devuelve InvalidArgument (HTTP 400). Ambos filtros se aplican después de consolidar los intentos en el más reciente, por lo que una ejecución coincide según el estado de su último intento y un filtro nunca vuelve a mostrar un intento reemplazado. Los tokens de página incluyen los filtros con los que se emitieron, así que reinicia la paginación cuando cambie un filtro.
• Añadido. List Pull Request Comments acepta los parámetros de consulta opcionales since y until: límites inclusivos de la fecha de creación de los comentarios, expresados como marcas de tiempo RFC 3339, por ejemplo 2026-08-01T00:00:00Z. Una marca de tiempo mal formada devuelve InvalidArgument (HTTP 400). Los tokens de página incluyen los límites con los que se emitieron, así que reinicia la paginación cuando cambie un límite. Usa since para seguir los comentarios nuevos en lugar de volver a paginar todo el historial de comentarios de un pull request.
• Cambiado. Las operaciones cuyos alcances requeridos provienen de la credencial y no de una concesión de instalación marcan su extensión x-origin-scopes con ambient: true en la especificación de OpenAPI publicada. Nueve operaciones incluyen este flag, entre ellas Get Authenticated App, Crear token de acceso de instalación y Listar repositorios de la instalación de la aplicación. Las cadenas de scope se mantienen en la extensión para que las respuestas 403 sigan indicándolas, y el procesamiento de las solicitudes no cambia; consulta el flag para distinguir las operaciones para las que solo necesitas autenticarte de las que requieren un scope aprobado durante la instalación.

• Cambio incompatible. List Check Suites For Commit, List Check Runs For Commit y List Check Runs For Suite devuelven solo el intento más reciente de cada comprobación y omiten los intentos reemplazados, en consonancia con lo que ya mostraban el control de fusión y las vistas de CI del producto. Una suite de comprobación se reduce a su intento más reciente por actor que informa y clave de suite, y una ejecución, a su intento más reciente por clave de ejecución dentro de una suite, de modo que una ejecución fallida y su reintento correcto ya no aparecen a la vez. totalSize y los tokens de página cuentan el conjunto reducido. Migración: consulta un intento reemplazado por su propio id mediante Obtener ejecución de comprobación o Get Check Suite, que siguen dando acceso a todos los intentos almacenados.
• Añadido. Create Pull Request Comment acepta un anclaje file que abre un hilo de comentarios sobre un archivo completo en el diff de la versión del pull request. Solo incluye file.path: Origin deduce el lado a partir del tipo de cambio del archivo (la versión base para un archivo eliminado y la versión de cabecera en los demás casos) y lo devuelve en thread.side. Envía la ruta eliminada si se trata de una eliminación y la ruta de cabecera para cualquier otro cambio; una ruta fuera del diff o la ruta original de un archivo renombrado devuelve InvalidArgument (HTTP 400). file, inline y threadId son mutuamente excluyentes. Create Pull Request Review admite el mismo anclaje como comments[].file.
• Añadido. Los actores de usuario públicos incluyen displayName y handle junto con id y email. displayName es el nombre y el apellido de la cuenta separados por un espacio, el mismo nombre que muestra el producto, y se omite cuando la cuenta no tiene nombre. handle es el identificador de perfil reclamado sin el prefijo @, y solo está presente mientras ese perfil sea visible públicamente. Ambos aparecen en todos los lugares donde aparece un actor de usuario, incluidos los autores de pull requests y comentarios, los actores de ejecuciones y suites de comprobación, los descartes de revisiones, los revisores solicitados, el installedBy de una instalación y los payloads de webhook correspondientes. El recibo de instalación incluye displayName, pero nunca handle.
• Añadido. Los actores de aplicación públicos incluyen el displayName registrado de la aplicación junto con id y slug, y el objeto app de los cinco payloads de webhook installation.* también lo incluye. Se omite cuando no se puede resolver la aplicación y en el actor gestionado propio de Cherri Code.
• Modificado. Solicitar un scope :write también concede el scope :read correspondiente, de modo que a una instalación que solicita repository:labels:write se le concede también repository:labels:read. Esto se aplica al instalar una aplicación, al previsualizar una instalación y cuando un token de acceso de instalación restringe sus scopes; además, una credencial existente de solo escritura ahora permite la lectura correspondiente. Los scopes de lectura siguen sin conceder permisos de escritura.

• Añadido. repository.deleted se envía cuando se elimina un repositorio, ya sea al eliminar desde el producto un repositorio nativo o saliente, o al detener la sincronización de una réplica entrante. El payload incluye una referencia repository y deletedAt en lugar de una instantánea, porque un repositorio eliminado ya no se puede resolver a través de la API. Para suscribirse se requiere repository:metadata:read. A diferencia de repository.pushed, este evento sí se envía para repositorios replicados desde GitHub, ya que detener la sincronización solo elimina el repositorio del lado de Cherri Code y GitHub no envía nada al respecto. Volver a eliminar un repositorio ya eliminado no emite ningún evento.
• Añadido. repository.metadata.updated se envía cuando cambia la rama predeterminada de un repositorio, ya sea por escrituras desde la configuración o la API, por una réplica entrante que sigue un cambio de nombre en el repositorio de origen o por la reconciliación de la rama principal en el primer push. El payload incluye la instantánea completa de repository posterior a la escritura, sin delta ni actor que realizó la actualización, así que compara instantáneas sucesivas o vuelve a obtener el repositorio para ver qué ha cambiado. Para suscribirse se requiere repository:metadata:read.
• Añadido. Los usuarios revisores solicitados incluyen un email junto a id. Aparece en List Pull Request Requested Reviewers y Request Pull Request Reviewers, y en la entrada reviewer.user de los webhooks pull_request.reviewer.added, pull_request.reviewer.removed y pull_request.reviewer.rerequested. El valor es la dirección de correo electrónico de la cuenta y está vacío si la cuenta no tiene ninguna. Hasta ahora, estos puntos identificaban a un usuario únicamente por su id.
• Cambiado. Las respuestas REST incluyen los campos que tienen su valor predeterminado en lugar de omitirlos, de modo que un booleano false, un número 0, una cadena vacía y un array vacío aparecen en todos los cuerpos de respuesta. Una pull request que no es borrador obtenida con Get Pull Request devuelve draft como false en lugar de omitirlo, y una lista vacía devuelve [] en lugar de nada. Los campos que el contrato marca como opcionales, como submitted_at y dismissal, siguen sin aparecer cuando no están establecidos. Si tu integración trataba una clave ausente como el valor predeterminado, lee directamente el valor. Así se alinea con la forma en que siempre se han serializado los payloads de webhooks.
• Cambiado. Cada operación de la especificación de OpenAPI publicada tiene un operationId único. Cuando una operación responde a dos estructuras de URL, la segunda recibe el sufijo _2: OriginService_GetRepoTarball_2 para GET …/tarball/{ref} y OriginService_ListMatchingGitRefs_2 para GET …/git/matching-refs. Ambas estructuras de URL y la forma de gestionar sus solicitudes no cambian, así que regenera cualquier cliente creado a partir de la especificación para incorporar los métodos renombrados.
• Cambiado. installation.updated también se envía cuando se renombra el espacio de nombres del propietario, una vez por cada instalación que siga perteneciendo a ese espacio de nombres. El evento incluye el nuevo slug del espacio de nombres junto con los scopes actuales y la selección de repositorios de esa instalación.

• Cambiado. Cada operación de la especificación de OpenAPI publicada incluye una extensión x-origin-scopes que indica el scope que requiere la operación y las credenciales que acepta. scopes contiene el alcance requerido y tokenTypes, los tipos de credenciales aceptados: app para un JWT de aplicación, installation para un token de acceso de instalación y user para una credencial de usuario. Si la operación rechaza un tipo de credencial, este no aparece en tokenTypes. Obtener límite de uso es la única operación que no requiere ningún scope. La extensión también sustituye las frases sobre scopes que Create Label, Update Label y Delete Label incluían en sus descripciones. La autorización no cambia: la extensión solo publica los scopes que Origin ya aplicaba.

• Añadido. List Pull Request Requested Reviewers devuelve los usuarios y grupos cuya revisión sigue pendiente en un pull request: GET /v1/origin/repos/{ownerSlug}/{repoName}/pulls/{pullNumber}/requested_reviewers. Una solicitud directa se elimina cuando ese usuario envía una revisión, y una solicitud de grupo se elimina cuando cualquier miembro actual del grupo envía la suya; en cambio, una revisión en borrador sin enviar mantiene la solicitud pendiente. Los revisores se devuelven como ids, y leerlos requiere repository:pull_requests:reviews:read.
• Añadido. Request Pull Request Reviewers solicita revisiones a usuarios y grupos y devuelve los revisores solicitados: POST /v1/origin/repos/{ownerSlug}/{repoName}/pulls/{pullNumber}/requested_reviewers. Identifica a cada revisor por su public id user_…, correo electrónico, id grp_… o slug de grupo; los nombres para mostrar no se resuelven, un identificador desconocido o ambiguo devuelve InvalidArgument (HTTP 400) y un revisor que no es candidato para el repositorio devuelve PermissionDenied (HTTP 403). Volver a solicitar a un revisor ya solicitado reactiva la solicitud, de modo que un revisor que ya había enviado una revisión vuelve a aparecer como pendiente. Requiere repository:pull_requests:reviews:write.
• Añadido. Remove Pull Request Requested Reviewers elimina las solicitudes de revisión pendientes y devuelve 204 con el cuerpo vacío: DELETE /v1/origin/repos/{ownerSlug}/{repoName}/pulls/{pullNumber}/requested_reviewers. Eliminar a un revisor que no tiene una solicitud activa no tiene ningún efecto, y un public id estable se sigue resolviendo aunque ese revisor ya no figure en la lista de candidatos del repositorio, por lo que es posible eliminar una solicitud obsoleta. Requiere repository:pull_requests:reviews:write.
• Añadido. Update Pull Request Thread resuelve o reabre un hilo de comentarios de un pull request y devuelve su estado actualizado: PATCH /v1/origin/repos/{ownerSlug}/{repoName}/pulls/threads/{threadId}. Envía resolved como true para resolverlo o como false para reabrirlo. Ambas operaciones son idempotentes, responder a un hilo resuelto no lo reabre y un hilo almacenado en otro repositorio devuelve 404. Requiere repository:pull_requests:reviews:write.
• Añadido. Los comentarios de pull request incluyen su hilo completo en lugar de solo el id del hilo. thread ahora incluye la version a la que se asocia, con sus SHA de head y base; los campos path, side, startLine y endLine del anclaje del hilo en el diff; resolvedAt, y los propios createdAt y updatedAt del hilo. Lo devuelven List Pull Request Comments, Get Pull Request Comment y Update Pull Request Comment. thread.id no cambia, así que agrupar comentarios por este campo sigue funcionando.
• Añadido. Create Pull Request Comment acepta un anclaje inline, formado por path, side, startLine y un endLine opcional, que abre un hilo anclado a una línea en el diff de una versión del pull request, además de un versionNumber que indica la versión a la que se asocia y que, de forma predeterminada, es la más reciente en el momento de la llamada. El path debe formar parte del diff de esa versión en un lado donde el archivo tenga contenido; se puede anclar cualquier línea de un archivo modificado, no solo las que están dentro de un fragmento del diff, y un anclaje no válido devuelve InvalidArgument (HTTP 400) en lugar de convertirse en un comentario de discusión general. inline y threadId son mutuamente excluyentes, al igual que threadId y versionNumber.
• Añadido. Create Pull Request Review acepta un array comments, con un máximo de 50 por solicitud, que publica una revisión junto con sus comentarios en una única llamada atómica. Cada entrada incluye un body y los mismos destinos que Create Pull Request Comment: un anclaje inline en el diff de la versión revisada, una respuesta con threadId o ninguno de los dos para crear un nuevo hilo de discusión general. Todos los anclajes se validan antes de escribir nada, por lo que un solo anclaje no válido hace que falle toda la solicitud con InvalidArgument (HTTP 400) y no se publica nada. La operación no admite clave de idempotencia, así que consulta List Pull Request Reviews antes de reintentar tras un fallo ambiguo. Las solicitudes sin comments se comportan igual que antes.
• Añadido. pull_request.comment.created incluye el anclaje en el diff del hilo en el comentario que lo abrió, para que un receptor pueda materializar el hilo sin tener que hacer una lectura adicional. comment.thread contiene los valores version, path, side, startLine y endLine sobre los que se registró el comentario; una respuesta incluye solo comment.thread.id, y el estado de resolución no forma parte del evento. Los comentarios registrados junto con una revisión mediante Create Pull Request Review no emiten nada hasta que se envía la revisión; en ese momento, cada uno emite su propio evento.

• Añadido. Get Repo Tarball descarga un tar comprimido con gzip del árbol de un repositorio: GET /v1/origin/repos/{ownerSlug}/{repoName}/tarball/{ref}. La primera solicitud para un commit resuelto transmite application/gzip como cuerpo de la respuesta; las solicitudes posteriores para el mismo commit devuelven 302 con una URL de descarga firmada en Location, válida durante 15 minutos. Las entradas del archivo se sitúan en la raíz del tar, sin un directorio contenedor; un repositorio vacío devuelve ABORTED (HTTP 409 Conflict), y para descargar un archivo se necesita repository:contents:read.
• Añadido. List Comparison Files enumera los archivos modificados en una comparación, es decir, el diff de head frente a la base de fusión de base y head: GET /v1/origin/repos/{ownerSlug}/{repoName}/compare/{basehead}/files. Los resultados se paginan, con 30 archivos por página de forma predeterminada y 100 como máximo, y cada archivo tiene la misma estructura que devuelve List Commit Files. Una comparación identical o behind devuelve una lista vacía, los historiales sin relación devuelven 404, y una comparación cuyos commits cambian durante la paginación rechaza el token de página con InvalidArgument (HTTP 400), por lo que el listado vuelve a empezar desde la primera página. Para leer los archivos de una comparación se necesita repository:contents:read.
• Añadido. El endpoint de claves de firma envía Cache-Control: public, max-age=600, stale-if-error=600. Reutiliza un JWKS en caché durante 10 minutos y luego actualízalo; si una actualización falla, conserva las últimas claves válidas durante 10 minutos más como máximo antes de dar por fallida la verificación. Actualiza también cuando ninguna clave activa pueda verificar una firma, para que se descarten los ID de clave retirados.
• Cambiado. Un check run que siga en in_progress cuando venza su deadlineAt se completa con la conclusión timed_out y envía repository.check_run.completed. Esto sustituye a la nota del 27 de agosto, que indicaba que una fecha límite no cambia el estado de un run. La expiración se ejecuta mediante un barrido periódico y no con un temporizador por run, por lo que un run puede superar brevemente su fecha límite. Un run queued nunca expira, como tampoco un run sin deadlineAt, y Origin conserva el externalUpdatedAt del run para que una finalización posterior de tu proveedor pueda sobrescribir la conclusión timed_out.
• Cambiado. repository.pushed ya no se envía para los repositorios que Origin replica desde GitHub. GitHub gestiona esos pushes y envía sus propios webhooks de push, por lo que el envío de Origin los duplicaba. Los pushes a repositorios nativos de Origin y a réplicas salientes se siguen enviando igual, y el estado de la réplica no afecta a ningún otro evento.
• Cambiado. Create Pull Request rechaza con InvalidArgument (HTTP 400) un head que no tenga historial en común con base, sin crear nada, en lugar de devolver el 404 que generaba la comparación subyacente.
• Cambiado. Un push que deje la cabecera de una pull request abierta sin historial en común con su base cierra la pull request y envía pull_request.closed. Un push relacionado posterior no la vuelve a abrir.
• Cambiado. Cada operación de la especificación de OpenAPI documenta los códigos de respuesta que puede devolver, en lugar de mostrar los mismos 400, 401, 403 y 429 en todas las operaciones: 404 en cada ruta con parámetros, 409 donde un handler notifique un conflicto, 202 en Batch Redeliver Webhook Deliveries y Sync Mirror, y conjuntos más reducidos en Get Rate Limit y Get Authenticated App. El esquema Status describe el envoltorio de error que devuelve Origin, e indica que un 404 nunca distingue entre un recurso inexistente y uno inaccesible; además, cada operación incluye un ejemplo de solicitud y de respuesta. El procesamiento de solicitudes no cambia; vuelve a generar cualquier cliente creado a partir de la especificación para obtener los nuevos modelos de respuesta.

• Añadido. Las ejecuciones de comprobación aceptan y devuelven una marca de tiempo deadlineAt opcional. Envíala en el cuerpo de la ejecución en Post Check Run o Batch Upsert Check Runs, y consúltala en Obtener ejecución de comprobación, List Check Runs For Suite y List Check Runs For Commit. Origin borra la fecha límite cuando la ejecución llega a completed, conserva el valor almacenado si una actualización omite el campo y rechaza con InvalidArgument (HTTP 400) cualquier fecha límite situada a más de 24 horas en el futuro, en lugar de ajustarla. Que venza una fecha límite no cambia el estado de la ejecución.
• Cambiado. La especificación de OpenAPI publicada declara https://api.cursor.com como servidor y un esquema de seguridad HTTP bearer bearerAuth, de modo que un cliente de red generado a partir del documento incorpora la URL base y el requisito Authorization: Bearer.
• Cambiado. Los parámetros de ruta de OpenAPI usan los mismos nombres que ya emplean las URL. Las vinculaciones generadas identifier.ownerSlug e identifier.name pasan a ser ownerSlug y repoName en las 55 operaciones con ámbito de repositorio, lo que permite que los generadores estándar de OpenAPI procesen el documento. Las URL de las solicitudes y su comportamiento no cambian; vuelve a generar cualquier cliente de red creado a partir de la especificación para incorporar los nuevos nombres de parámetros.
• Cambiado. Los enums publicados ya no incluyen sus entradas de valor cero *_UNSPECIFIED, como RULESET_ENFORCEMENT_UNSPECIFIED en Create Ruleset y PULL_REQUEST_REVIEW_VERDICT_UNSPECIFIED en Create Pull Request Review. Origin nunca aceptó ni devolvió esos valores, por lo que las solicitudes y respuestas no cambian.
• Cambiado. Todas las operaciones de la especificación documentan respuestas 400, 401, 403 y 429 con el cuerpo google.rpc.Status, en lugar de solo la respuesta genérica default. Consulta Errores para ver el cuerpo y la lista completa de estados.

• Cambio incompatible. Los payloads de webhook de revisores para pull_request.reviewer.added, pull_request.reviewer.removed y pull_request.reviewer.rerequested sustituyen el par reviewer.kind y reviewer.id por un revisor tipado, en el que está presente exactamente uno de reviewer.user o reviewer.group. Migración: lee reviewer.user.id donde antes leías reviewer.id con un reviewer.kind de user, y reviewer.group.id donde reviewer.kind era group.
• Añadido. List Labels devuelve las definiciones de etiquetas de un repositorio, ordenadas por nombre: GET /v1/origin/repos/{ownerSlug}/{repoName}/labels. Para leer etiquetas se necesita el nuevo scope repository:labels:read. Los resultados están paginados, con 30 etiquetas por página de forma predeterminada y un máximo de 100.
• Añadido. Create Label define una etiqueta en un repositorio y la devuelve: POST /v1/origin/repos/{ownerSlug}/{repoName}/labels. Toda escritura de etiquetas requiere el nuevo scope repository:labels:write. name admite un máximo de 50 caracteres y description de 255; color debe tener seis caracteres hexadecimales sin # inicial, y si el nombre ya lo usa otra etiqueta del repositorio, la solicitud se rechaza con AlreadyExists (HTTP 409 Conflict).
• Añadido. Get Label devuelve una etiqueta del repositorio por su nombre: GET /v1/origin/repos/{ownerSlug}/{repoName}/labels/{labelName}. Si el nombre no existe, devuelve 404.
• Añadido. Delete Label elimina una etiqueta del repositorio por su nombre y devuelve 204: DELETE /v1/origin/repos/{ownerSlug}/{repoName}/labels/{labelName}. Al eliminar una etiqueta, también se quita de todos los pull requests a los que estaba asignada.
• Añadido. Update Label cambia el nombre, el color o la descripción de una etiqueta, identificándola por su nombre actual: PATCH /v1/origin/repos/{ownerSlug}/{repoName}/labels/{labelName}. Los campos omitidos no se modifican, y si se intenta cambiar el nombre a uno que ya usa otra etiqueta, la solicitud se rechaza con AlreadyExists (HTTP 409 Conflict).
• Añadido. List Check Run Annotations devuelve las anotaciones de una ejecución de comprobación en orden ascendente de ID, que coincide con el orden de creación: GET /v1/origin/repos/{ownerSlug}/{repoName}/check-runs/{checkRunId}/annotations. Para leerlas se necesita repository:checks:read. Los resultados están paginados, con 30 anotaciones por página de forma predeterminada y un máximo de 100.
• Añadido. Create Check Run Annotations añade entre 1 y 25 anotaciones a una ejecución de comprobación en un único lote atómico y las devuelve: POST /v1/origin/repos/{ownerSlug}/{repoName}/check-runs/{checkRunId}/annotations. Para añadirlas se necesita repository:checks:write. Una ejecución de comprobación admite como máximo 100 anotaciones, y un lote que supere ese límite se rechaza con ResourceExhausted (HTTP 429) sin escribir nada. La operación es de solo anexado y no es idempotente, por lo que un reintento tras un fallo ambiguo puede generar duplicados.
• Añadido. List Pull Requests admite cinco parámetros de consulta nuevos: author, un ID público de actor tal como lo devuelve la respuesta en pullRequests[].author.user.id, pullRequests[].author.app.id o pullRequests[].author.serviceAccount.id; base, un filtro exacto de rama base que acepta un nombre corto o una ref completa; direction, desc para mostrar primero los más recientes (valor predeterminado) o asc para mostrar primero los más antiguos; y since y until, límites inclusivos en formato RFC 3339 sobre la fecha de creación. Un autor sin pull requests devuelve una lista vacía, y cualquier otro valor no válido devuelve InvalidArgument (HTTP 400).
• Añadido. pull_request.review.dismissed se entrega cuando se descarta una revisión enviada, ya sea de forma explícita o porque una decisión más reciente la reemplaza. Tiene la misma estructura de payload que pull_request.review.submitted, con review.dismissal completado, y para suscribirse a él se necesita repository:pull_requests:reviews:read.
• Añadido. Las instalaciones indican qué usuario instaló la aplicación. installedBy, que contiene el ID público user_… y el correo electrónico de ese usuario, se devuelve en Get App Installation y List App Installations, y se incluye en cada instantánea de webhook installation.*. Allí identifica a quien realizó la instalación original y se omite cuando ya no es posible leer el registro de ese usuario. El recibo de instalación incorpora una afirmación installedBy que indica qué usuario realizó esa instalación o nuevo consentimiento, por lo que, tras un nuevo consentimiento, ambos valores pueden ser distintos.

• Añadido. Ping Webhook envía una entrega de prueba a la URL de webhook configurada de tu aplicación e informa de lo que respondió el receptor: POST /v1/origin/app/webhook/pings. La entrega se firma igual que una de producción, lleva webhook-event-type con el valor ping y no pertenece a ninguna instalación. Origin la envía una sola vez, sin reintentos, y nunca aparece en List Webhook Deliveries. Si la aplicación no tiene configurada una URL de webhook, la solicitud se rechaza con FailedPrecondition (HTTP 400).
• Añadido. Las respuestas de error incluyen el ID de solicitud dos veces: en el encabezado de respuesta X-Request-ID y en una entrada google.rpc.RequestInfo dentro de details. Origin devuelve el x-request-id que enviaste o genera uno si no envías ninguno, e incluye la entrada incluso cuando el mensaje es un error interno opaco. Consulta Errores.
• Cambiado. Create Pull Request y Update Pull Request rechazan un title de más de 256 caracteres o un body de más de 65.536 caracteres con InvalidArgument (HTTP 400). Antes, los valores que superaban esas longitudes fallaban con un error interno. Ambos límites cuentan puntos de código Unicode, por lo que un carácter astral, como un emoji, cuenta como uno solo.
• Cambiado. Las respuestas de Sync Mirror siempre incluyen synced, con valor true o false, en correspondencia con el estado HTTP: 200 cuando es true y 202 cuando es false. Antes, el campo se omitía cuando era false, por lo que el llamador tenía que interpretar su ausencia como false.
• Cambiado. Las rutas sin coincidencia bajo /v1/origin y las solicitudes que usan un método incorrecto en una ruta conocida devuelven el envoltorio de error documentado en lugar de un cuerpo genérico del enrutador. El mensaje indica el método y la ruta, y nunca incluye la cadena de consulta.
• Cambiado. Al fusionar un pull request se entrega un webhook repository.pushed para la referencia base que avanza con la fusión. Como es Origin quien hace ese push, el evento no indica ningún autor del push. Antes, las actualizaciones de la referencia base producidas por una fusión no se entregaban.

• Cambio. Create Pull Request Comment y Update Pull Request Comment rechazan un body de más de 65.536 caracteres con InvalidArgument (HTTP 400). Antes, un cuerpo que superaba esa longitud fallaba con un error interno. El límite cuenta puntos de código Unicode, por lo que un carácter astral, como un emoji, cuenta como uno solo.

• Añadido. Delete Ruleset elimina un ruleset de un repositorio mediante su ID estable de Origin y devuelve 204: DELETE /v1/origin/repos/{ownerSlug}/{repoName}/rulesets/{rulesetId}. Requiere repository:rulesets:write. Un ruleset almacenado en otro repositorio se trata como desconocido, y un rulesetId vacío se rechaza con InvalidArgument (HTTP 400).
• Añadido. Todos los endpoints con scope de repositorio permiten identificar un repositorio por su ID estable, además de por propietario y nombre: envía _ como slug del propietario y el ID como nombre del repositorio, por ejemplo GET /v1/origin/repos/_/REPO_ID. Obtén el ID del campo id de Get Repo. El ID se conserva aunque se cambie el nombre, pero no otorga ningún permiso por sí solo: tu aplicación necesita el mismo scope en el repositorio resuelto, y un ID al que no puede acceder devuelve el mismo 404 que un ID inexistente. Crear repositorio solo acepta un slug de propietario y rechaza _.
• Cambiado. Las aplicaciones ahora pueden acceder a repositorios replicados. Una réplica puede seleccionarse en una instalación, aparece en Listar repositorios de la instalación de la aplicación y en los arrays de repositorios del payload del webhook de la instalación, puede indicarse en repositoryIds en Crear token de acceso de instalación y recibe entregas de webhooks. Mientras una réplica no se convierta en una réplica saliente estable, será de solo lectura: solo se aplican repository:metadata:read y repository:contents:read, y cualquier otro scope devuelve 403 en ese repositorio, incluido git push. Consulta Repositorios replicados.

• Cambio incompatible. El parámetro de consulta recursive en Get Tree es un booleano en lugar de una cadena, por lo que solo true y 1 recorren el árbol completo; cualquier otro valor, incluidos false, 0 y un ?recursive sin valor, lista únicamente los hijos inmediatos. Migración: envía recursive=true en todos los casos en los que tu integración dependiera de que cualquier valor no vacío de recursive activara la recursión.
• Cambio incompatible. Los payloads de webhook del ciclo de vida de los pull requests omiten las labels asignadas al pull request, lo que sustituye al campo anunciado el 20 de agosto de 2026. Las respuestas REST lo siguen incluyendo. Migración: lee las etiquetas desde Get Pull Request o List Pull Requests en lugar de la instantánea del webhook.
• Añadido. List Rulesets devuelve todos los rulesets configurados en un repositorio junto con una única referencia repository compartida: GET /v1/origin/repos/{ownerSlug}/{repoName}/rulesets. Los rulesets son una configuración acotada, por lo que la respuesta no está paginada. Para leer rulesets se requiere repository:rulesets:read.
• Añadido. Create Ruleset guarda un nuevo ruleset y lo devuelve con los ID que Origin asigna a cada regla y actor de omisión: POST /v1/origin/repos/{ownerSlug}/{repoName}/rulesets. Ambos endpoints de escritura de rulesets requieren repository:rulesets:write.
• Añadido. Get Ruleset devuelve un único ruleset a partir de su ID estable de Origin: GET /v1/origin/repos/{ownerSlug}/{repoName}/rulesets/{rulesetId}.
• Añadido. Update Ruleset reemplaza por completo la configuración de un ruleset, incluidos sus rules y bypassActors: PUT /v1/origin/repos/{ownerSlug}/{repoName}/rulesets/{rulesetId}. Envía todas las reglas y actores de omisión que quieras conservar, ya que las entradas almacenadas se reemplazan en lugar de fusionarse.
• Añadido. Los rulesets incluyen id, name, description, enforcement (active, evaluate o disabled), kind (merge_branch, push_branch, push_tag o push_repository), los patrones includedRefNames y excludedRefNames (que admiten globs y los tokens ~ALL y ~DEFAULT_BRANCH), rules y bypassActors. Create Ruleset y Update Ruleset devuelven InvalidArgument (HTTP 400) si se superan los 64 patrones por lista, las 20 reglas o los 15 actores de omisión.
• Añadido. Merge Pull Request acepta un campo de solicitud opcional expectedHeadSha: el SHA completo del commit con el que debe coincidir la cabecera del pull request. Si la cabecera ha cambiado, la fusión se rechaza con ABORTED (HTTP 409 Conflict) y no se fusiona nada; un valor que no sea un SHA de commit completo se rechaza con InvalidArgument (HTTP 400). Omítelo para fusionar independientemente de cuál sea la cabecera actual.
• Añadido. Las referencias de propietario incluyen una cadena type (team o user), que se omite cuando Origin no puede resolverla. Se devuelve siempre que aparece un owner o un target de instalación, por ejemplo en Get Repo, List Repos, List App Installations y en la referencia de repositorio de las respuestas de checks y pull requests.

• Cambio incompatible. Listar etiquetas de pull requests devuelve todas las etiquetas asignadas en una sola respuesta y ya no usa paginación: se eliminaron los parámetros de consulta pageSize y pageToken y el campo de respuesta nextPageToken. Migración: quita pageSize y pageToken de la solicitud y lee el conjunto completo en labels.
• Cambio incompatible. Un pull request admite como máximo 100 etiquetas, y Añadir etiquetas de pull requests y Establecer etiquetas de pull requests rechazan con FailedPrecondition (HTTP 400) cualquier escritura que supere ese límite. Migración: mantén cada pull request en 100 etiquetas o menos y elimina etiquetas antes de añadir otras nuevas.
• Añadido. Los pull requests incluyen un array labels con las etiquetas que tienen asignadas, ordenadas por nombre; si no hay ninguna asignada, el array está vacío. Lo devuelven Listar pull requests, Obtener pull request, Crear pull request, Actualizar pull request y Fusionar pull request, y también se incluye en los payloads de webhook del ciclo de vida de los pull requests.

• Añadido. Listar etiquetas de pull requests devuelve las etiquetas asignadas a una pull request, ordenadas por nombre: GET /v1/origin/repos/{ownerSlug}/{repoName}/pulls/{pullNumber}/labels. Requiere repository:pull_requests:read. Los resultados están paginados, con 30 etiquetas por página de forma predeterminada y un máximo de 100 por página.
• Añadido. Añadir etiquetas a pull requests asigna etiquetas existentes del repositorio a una pull request sin quitar las que ya tiene: POST /v1/origin/repos/{ownerSlug}/{repoName}/pulls/{pullNumber}/labels. Todos los endpoints de escritura de etiquetas requieren repository:pull_requests:write.
• Añadido. Establecer etiquetas de pull requests reemplaza todas las etiquetas de una pull request por los nombres que envíes; si envías una lista vacía, se eliminan todas: PUT /v1/origin/repos/{ownerSlug}/{repoName}/pulls/{pullNumber}/labels.
• Añadido. Eliminar etiqueta de pull request elimina una etiqueta por su nombre y devuelve las etiquetas que quedan en la pull request: DELETE /v1/origin/repos/{ownerSlug}/{repoName}/pulls/{pullNumber}/labels/{labelName}.
• Añadido. Eliminar todas las etiquetas de pull request quita todas las etiquetas de una pull request y devuelve 204: DELETE /v1/origin/repos/{ownerSlug}/{repoName}/pulls/{pullNumber}/labels.
• Añadido. Las entradas de etiqueta incluyen id, name, color (un valor hexadecimal de seis caracteres sin # inicial) y una description opcional. Todos los endpoints de etiquetas de pull requests las devuelven.
• Cambiado. El presupuesto del límite de uso del JWT de aplicación pasa de 600 a 6000 puntos por minuto, y Crear token de acceso de instalación cuesta 1 punto en lugar de 5, por lo que una aplicación puede emitir unos 100 tokens de acceso de instalación por segundo.
• Cambiado. Los requisitos de propietario para Crear repositorio y para hacer push mediante Git por HTTPS ahora admiten los planes Pro Student y Start, además de Pro, Pro+ y Ultra. Los requisitos para equipos propietarios no cambian.
• Cambiado. Los slugs de propietario y los nombres de repositorio en las rutas de repositorio se resuelven sin distinguir entre mayúsculas y minúsculas, y las respuestas devuelven las mayúsculas y minúsculas almacenadas en lugar de las que enviaste. Crear repositorio rechaza cualquier nombre que solo se diferencie en mayúsculas o minúsculas de otro que ya tenga el propietario, así que compara los nombres de repositorio sin distinguir entre mayúsculas y minúsculas.

• Cambio incompatible. Git por HTTPS rechaza un push con 403 cuando el propietario del repositorio no está habilitado para escribir en Origin. Si el propietario es un usuario, debe tener un plan Pro, Pro+ o Ultra; si es un equipo, debe tener un plan de equipo de pago activo, no debe usar el modo de privacidad (heredado) y un administrador de equipo no debe haber desactivado Origin. Las operaciones clone, fetch y pull no se ven afectadas. Migración: trata el 403 en un push como un error de habilitación del propietario que no se soluciona con un reintento, y confirma el plan del propietario antes de hacer push en su nombre.
• Modificado. El primer push a un repositorio creado con Crear repositorio reasigna defaultBranch cuando ese push solo crea ramas y ninguna de ellas es la predeterminada almacenada: Origin elige la rama creada o, si el push crea varias y una de ellas se llama main o master, elige esa. Consulta el valor actual en Get Repo.

• Cambio incompatible. Crear repositorio rechaza las solicitudes cuyo propietario no cumple los requisitos para escribir en Origin y devuelve FailedPrecondition (HTTP 400). Si el propietario es un usuario, debe tener un plan Pro, Pro+ o Ultra; si es un equipo, debe tener un plan de equipo de pago activo, no debe usar el modo de privacidad (heredado) y un administrador de equipo no debe haber desactivado Origin. Migración: trata el error 400 de Crear repositorio como un fallo de requisitos del propietario que no se resuelve con un reintento, y confirma el plan del propietario antes de crear repositorios en su nombre.

• Cambio incompatible. Las aplicaciones perdieron el acceso a los repositorios que Origin replica desde GitHub. Esos repositorios ya no aparecen en Listar repositorios de la instalación de la aplicación, Crear token de acceso de instalación los rechaza en repositoryIds y cualquier solicitud que haga referencia a uno de ellos devuelve 403, tanto en la API REST como en Git por HTTPS. Migración: obtén los repositorios desde Listar repositorios de la instalación de la aplicación en lugar de usar una lista de repositorios almacenada, y lee los repositorios procedentes de GitHub directamente desde GitHub, no desde la API de Origin.
• Cambio incompatible. Origin dejó de enviar webhooks para los repositorios que replica desde GitHub, y los payloads de eventos de instalación ya no incluyen esos repositorios en sus arrays de repositorios seleccionados ni en repositoriesCount. Migración: obtén los eventos de los repositorios procedentes de GitHub directamente desde GitHub y considera el array de repositorios del payload de instalación como el conjunto de repositorios a los que tu aplicación puede acceder.

• Cambio. Los parámetros de revisión aceptan la referencia simbólica HEAD, además de un SHA, una rama o una etiqueta: sha en List Commits, Get Commit, List Commit Files, Get Git Commit y Get Tree; ref en Get Contents y Batch Get Contents; y cualquiera de los dos lados de basehead en Compare Commits.
• Cambio. Get Git Ref resuelve la referencia simbólica HEAD y la devuelve como ref: "HEAD" junto con el commit de la punta. List Matching Git Refs y List Matching Git Refs by Path solo coinciden con HEAD de forma exacta, ya que no se encuentra bajo refs/.
• Cambio. Al quitar una instalación o eliminar la aplicación, los tokens de acceso de esa instalación se invalidan antes de expiresAt. La API REST y Git por HTTPS rechazan los tokens revocados con 401, por lo que es necesario volver a instalar la aplicación para que pueda emitir uno válido. Consulta Token de acceso de instalación.

• Cambio incompatible. Get Contents rechaza los archivos de más de 1 MiB (decodificados) con FailedPrecondition (HTTP 400), y basta un solo archivo que supere ese tamaño para que falle toda la solicitud de Batch Get Contents.
• Añadido. Los tokens de acceso de instalación permiten autenticarse en Git por HTTPS. Usa el token como contraseña de HTTP Basic con el nombre de usuario x-access-token en el cloneUrl del repositorio. Clonar, hacer fetch y hacer pull requieren repository:contents:read; hacer push requiere repository:contents:write. Consulta Autenticación de Git por HTTPS.
• Modificado. cloneUrl usa ahora la ruta raíz con estructura de GitHub (https://origin.cursor.com/OWNER_SLUG/REPO_NAME.git) en lugar de la ruta heredada /git/ en List Repos, Get Repo, Crear repositorio, Listar repositorios de la instalación de la aplicación y el payload del webhook repository.created. Ambas formas permiten clonar y cloneUrl no garantiza ninguna estructura de ruta concreta, así que los valores almacenados siguen funcionando.
• Modificado. size en las respuestas de Get Contents y Batch Get Contents indica el tamaño del contenido decodificado en bytes, no la longitud de la cadena content en base64.

• Cambio incompatible. Los payloads de webhook de revisores incluyen un ID externo estable en reviewer.id: el ID de usuario codificado (user_…, el mismo formato que en la API de organización) cuando kind es user, en lugar del ID de autenticación con scope del proveedor; los revisores de grupo conservan el public id del grupo (grp_…). Afecta a pull_request.reviewer.added, pull_request.reviewer.removed y pull_request.reviewer.rerequested. Migración: identifica a los revisores de tipo usuario por el ID codificado user_… en todos los puntos en los que tu integración comparaba reviewer.id con los ID de autenticación almacenados.
• Añadido. Las aplicaciones pueden tener hasta 10 claves de firma Ed25519 activas, y la verificación del JWT de aplicación acepta tokens firmados con cualquiera de ellas.
• Añadido. Sincronizar réplica sincroniza una ref de un repositorio replicado desde su origen: POST /v1/origin/repos/{ownerSlug}/{repoName}:syncMirror. Requiere repository:contents:read y devuelve 200 cuando se alcanza el objetivo de sincronización o 202 mientras la sincronización está pendiente.
• Añadido. Las redirecciones posteriores a la instalación incluyen un parámetro de consulta installation_receipt: un JWT firmado por Origin, válido durante cinco minutos, que identifica la instalación en su afirmación sub y devuelve el state del editor como afirmación. Verifícalo con el JWKS publicado antes de confiar en el callback. Consulta Recibo de instalación.
• Eliminado. Los objetos de actor de Origin ya no incluyen los campos de nivel superior kind e id, con lo que se completa la retirada anunciada el 5 de agosto de 2026. Afecta a todos los campos actor, author y dismissedBy de las respuestas de checks, commits y pull requests. Migración: lee la variante user, app o serviceAccount definida en el actor.

• Añadido. Obtener límite de uso devuelve el presupuesto compartido de puntos por minuto del principal autenticado sin consumir puntos: GET /v1/origin/rate_limit. Consulta Límites de uso.

• En desuso. OriginActor.kind y OriginActor.id. La identidad del actor es una unión discriminada de las variantes user, app y serviceAccount. Migración: lee los campos de la variante seleccionada en lugar de los campos kind e id de nivel superior.