Skip to main content

Command Palette

Search for a command to run...

API

Registro de alterações da API Origin

Alterações na API Origin pública, incluindo endpoints, esquemas de solicitação e resposta, escopos e webhooks, agrupadas por dia, com as mais recentes primeiro. Cada alteração tem um rótulo: Incompatível, Descontinuada, Adicionada, Alterada ou Removida. Alterações incompatíveis e descontinuadas incluem orientações de migração no próprio texto. A referência da API Origin sempre reflete o estado sincronizado mais recente.

  • Alterado. Merge Pull Request retorna Aborted (HTTP 409 Conflict) em vez de InvalidArgument (HTTP 400) quando o head branch do pull request avançou além do head da sua version mais recente, por exemplo, porque foi integrado um push que o Origin ainda não havia registrado como nova versão. É a mesma resposta dada a um expectedHeadSha desatualizado. Em nenhum dos casos o merge é feito; tente novamente depois que Get Pull Request informar o novo head em version.headSha.
  • Adicionado. List Namespaces lista os namespaces nos quais você pode listar repositórios, ordenados por slug: GET /v1/origin/namespaces. Os candidatos são os namespaces das suas equipes, seu namespace pessoal e os namespaces que contêm repositórios aos quais você recebeu acesso. Apenas os namespaces em que você tem namespace:repositories:read são retornados, de modo que cada namespace.slug é um ownerSlug válido para List Repos. O campo viewerCanCreateRepositories de cada entrada indica se uma chamada a Criar repositório nesse namespace passaria, no seu caso, pela autorização e pelas verificações de plano e de configurações do proprietário. As páginas contêm 30 namespaces por padrão e no máximo 100. Requer uma credencial de usuário do Cherri Code, não exige escopo e custa 1 ponto; tokens de app, tokens de acesso da instalação e contas de serviço recebem PermissionDenied (HTTP 403).
  • Alterado. Reabrir um pull request por meio de Update Pull Request registra uma nova version quando o head foi movido enquanto o pull request estava fechado e envia pull_request.head_ref.pushed. Antes, o pull request mantinha o head que tinha no momento do fechamento até a branch receber um novo push. A versão registrada tem seus próprios headSha, baseSha e estatísticas de diff, no mesmo formato registrado por um push. Pull requests mergeados não são afetados.
  • Alterado. Um SHA de commit abreviado enviado para Get Commit ou List Commit Files é resolvido da mesma forma que em Get Git Commit: apenas entre objetos de commit. Assim, um prefixo que identifica exatamente um commit é resolvido mesmo quando um blob ou tree no repositório compartilha esse prefixo. A entrada de 22 de setembro mencionava apenas Get Git Commit. Get Blob e Get Tag não foram alterados.

Apps e instalações

  • Alterado. Criar token de acesso da instalação informa que um token expira em no máximo 15 minutos e nunca depois do JWT do app que o solicitou. Leia expiresAt na resposta e emita um novo token quando esse prazo passar, em vez de presumir uma duração fixa.

Pull requests

  • Alteração incompatível. Create Pull Request não aceita mais parentPullNumber. Uma solicitação que o inclua retorna InvalidArgument (HTTP 400) indicando parent_pull_number em vez de criar o pull request. Assim, um client que continue enviando esse campo falha de forma explícita, em vez de perder silenciosamente o parent da stack. Migração: envie parentPullRequest com um membro number em todos os lugares onde sua integração enviava parentPullNumber.
  • Adicionado. Delete Pull Request Comment exclui um comentário de Pull Request pelo seu id no Origin: DELETE /v1/origin/repos/{ownerSlug}/{repoName}/pulls/comments/{commentId}. O autor do comentário sempre pode excluí-lo; qualquer outro chamador precisa ter acesso de gravação ao repositório por meio de repository:contents:write, caso contrário recebe PermissionDenied (HTTP 403). Excluir o último comentário de um thread remove o thread, enquanto excluir qualquer outro comentário mantém o thread. Em ambos os casos, as reações e o histórico de edições do comentário também são removidos. Um id desconhecido ou já excluído retorna 404. Requer repository:pull_requests:reviews:write e custa 5 pontos.
  • Adicionado. As respostas de pull request incluem um objeto stack com o id da stack e o parentPullRequest sobre o qual este pull request está empilhado. Esse objeto fica ausente quando o pull request não faz parte de uma stack e não inclui parentPullRequest na raiz. Ele é retornado por List Pull Requests, Get Pull Request, Create Pull Request, Update Pull Request e Merge Pull Request, e está presente em todo payload pull_request.*. Um stack entregue reflete a topologia no momento do evento em que foi enviado.
  • Adicionado. Create Pull Request e Update Pull Request aceitam parentPullRequest, um seletor que indica o parent da stack por number ou id, ou o remove com clear na atualização. Exatamente um membro deve ser definido; um seletor vazio, clear: false, mais de um membro ou clear na criação retornam InvalidArgument (HTTP 400). A edição é apenas uma associação: nenhuma branch é reescrita, e base só é redirecionado quando também é enviado. A atualização aplica o seletor depois de base, então um parent explícito prevalece sobre o parent derivado de uma alteração de base.
  • Adicionado. List Pull Requests aceita stackId, um id de stack no formato retornado em stack.id. Os membros dessa stack são retornados na ordem de classificação solicitada, e não na ordem da stack; por isso, recrie a stack a partir do stack.parentPullRequest de cada membro. O valor padrão de state continua sendo open, então passe state=all para obter a stack inteira. Um id bem formado que não corresponda a nenhuma stack no repositório retorna uma lista vazia, e qualquer outro valor retorna InvalidArgument (HTTP 400).
  • Adicionado. List Pull Requests aceita headSha, o SHA hexadecimal completo de 40 ou 64 caracteres do head de um pull request. Um pull request é selecionado quando qualquer uma de suas versões registradas tem esse head commit, seja atual ou substituída; por isso, compare head.sha em cada resultado para distinguir os dois casos. SHAs malformados, abreviados ou desconhecidos não retornam nenhum resultado.

Execuções de verificação

  • Obsoleto. checkRuns na resposta de Batch Upsert execução de verificação está obsoleto e foi substituído por results[].checkRun. Ele será removido em uma versão futura, mas continua sendo preenchido com as mesmas execuções, na mesma ordem. Migração: leia results[].checkRun, que associa cada execução armazenada ao outcome da respectiva gravação.
  • Adicionado. Post execução de verificação retorna outcome, e Batch Upsert execução de verificação retorna results[], com um item por execução enviada, na ordem da solicitação. Cada item associa checkRun ao seu próprio outcome. O valor é created, updated, unchanged ou ignored_stale. Um envio cujo externalUpdatedAt seja mais antigo que o carimbo armazenado é ignorado, e um envio que repete os valores armazenados não altera nada. Em ambos os casos, a resposta é 200 com a execução armazenada e updatedAt permanece inalterado; por isso, outcome é a única forma de diferenciá-los.
  • Alterado. O message de uma anotação de execução de verificação pode conter Markdown, que o Origin renderiza na Página da Pull Request, tanto na aba Checks quanto no cartão inline em Changes. Esse formato é aceito em Post execução de verificação e Batch Upsert execução de verificação e retornado por Obter execução de verificação. rawDetails continua sendo texto simples.

Dados do Git

  • Alterado. Get Git Commit resolve um sha abreviado somente quando ele tem pelo menos 5 caracteres hexadecimais, e apenas entre objetos de commit. A solicitação falha quando nenhum commit ou mais de um commit corresponde à abreviação. SHAs completos, branches, tags e HEAD continuam sendo resolvidos como antes.

Autoridades certificadoras SSH

  • Adicionado. List SSH Certificate Authorities lista as autoridades de certificação SSH em que um proprietário confia para git over SSH, da mais recente para a mais antiga, junto com requireCertificates, que indica se o proprietário exige certificados: GET /v1/origin/owners/{ownerSlug}/ssh-certificate-authorities. A resposta não é paginada, e cada entrada de certificateAuthorities[] contém id, name, keyType, fingerprint, publicKey e createdAt. Requer namespace:settings:read.
  • Adicionado. Add SSH Certificate Authority adiciona uma autoridade em que o proprietário confia e a retorna: POST /v1/origin/owners/{ownerSlug}/ssh-certificate-authorities. O corpo recebe um publicKey obrigatório, que é uma linha authorized_keys do OpenSSH cujo tipo de chave seja ssh-ed25519, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521 ou ssh-rsa com módulo de pelo menos 2048 bits, e um name obrigatório de no máximo 255 caracteres. Um certificado, um tipo de chave não compatível ou uma chave RSA menor retorna InvalidArgument (HTTP 400); uma chave que o proprietário já tem na lista retorna AlreadyExists (HTTP 409 Conflict), sendo a verificação feita no âmbito do proprietário, e não do Origin como um todo; e um proprietário que não pertence a uma equipe retorna FailedPrecondition (HTTP 400). Requer uma credencial de usuário do Cherri Code com namespace:settings:write.
  • Adicionado. Delete SSH Certificate Authority remove uma autoridade do proprietário e responde com 204 No Content: DELETE /v1/origin/owners/{ownerSlug}/ssh-certificate-authorities/{certificateAuthorityId}. Todos os certificados assinados pela autoridade deixam de funcionar e, enquanto o proprietário exigir certificados, a última autoridade dele não pode ser removida; a tentativa retorna FailedPrecondition (HTTP 400). Requer uma credencial de usuário do Cherri Code com namespace:settings:write.
  • Adicionado. Set SSH Certificate Requirement define se o proprietário exige certificados SSH: POST /v1/origin/owners/{ownerSlug}/ssh-certificate-authorities:setRequirement. O corpo recebe um booleano requireCertificates obrigatório, e a resposta contém a configuração requireCertificates do proprietário. Enquanto a exigência estiver ativa, o git over SSH nos repositórios do proprietário aceita apenas certificados das autoridades dele; assim, chaves SSH registradas por usuários e chaves de API de usuário via HTTPS são recusadas. Exigir certificados sem nenhuma autoridade na lista retorna FailedPrecondition (HTTP 400), e definir o valor atual é concluído com sucesso, sem nenhuma alteração. Requer uma credencial de usuário do Cherri Code com namespace:settings:write.

Webhooks

  • Adicionado. pull_request.comment.reaction.added e pull_request.comment.reaction.removed são webhook events nos quais é possível se inscrever, entregues quando uma reação é adicionada a um comentário de Pull Request ou removida dele. O payload compartilhado entre eles contém a referência pullRequest, uma referência comment com o respectivo thread e a reaction com os respectivos content e reactor. Uma adição é entregue pelo menos uma vez: adicionar novamente uma reação que o reator já tem entrega o evento outra vez para o mesmo comentário, reator e conteúdo, então consolide os eventos com base nesse trio. Remover uma reação que o reator não tem não gera nenhuma entrega.
  • Alterado. O payload de pull_request.label.removed contém actor, o principal que removeu o rótulo, quando conhecido. A entrada de 19 de setembro informava que actor era definido apenas em pull_request.label.added, mas ele é definido nos dois eventos quando o principal é conhecido.
  • Adicionado. Delete Git Ref exclui uma referência de branch: DELETE /v1/origin/repos/{ownerSlug}/{repoName}/git/refs/{ref}. O caminho identifica o branch como refs/heads/<branch> ou heads/<branch>, e somente referências de branch podem ser excluídas. Um branch inexistente retorna 404; o branch padrão do repositório, um branch protegido por uma regra de exclusão e um repositório cujo conteúdo é espelhado de outro host retornam FailedPrecondition (HTTP 400); e um branch cuja ponta muda durante a exclusão retorna FailedPrecondition (HTTP 400) ou Aborted (HTTP 409 Conflict). Nesse caso, tente novamente para excluir a nova ponta. Pull requests cujo head é o branch excluído são fechados, assim como acontece após uma exclusão via push. Requer repository:contents:write e custa 5 pontos.
  • Adicionado. pull_request.label.added e pull_request.label.removed são eventos de webhook que podem ser assinados, entregues quando um rótulo é atribuído a um pull request ou removido dele. O payload compartilhado entre eles contém a referência pullRequest e o snapshot label. Somente em pull_request.label.added, ele também inclui um actor que identifica o principal que atribuiu o rótulo. Excluir a definição de um rótulo entrega um pull_request.label.removed para cada pull request que tinha esse rótulo.
  • Alteração incompatível. Criar app passa a exigir que o proprietário do namespace esteja apto a fazer gravações no Origin, a mesma pré-condição que Criar repositório sempre exigiu. Uma solicitação em um namespace cujo proprietário seja um usuário que não esteja em um plano Pro, Pro Student, Pro+, Ultra ou Start, ou cujo proprietário seja uma equipe sem um plano de equipe pago ativo, no Privacy Mode (Legado) ou com o Origin desativado por um admin da equipe, retorna FailedPrecondition (HTTP 400), quando antes criava o app. A verificação considera a aptidão do proprietário do namespace, não a do usuário que faz a chamada. Migração: crie apps apenas em namespaces cujo proprietário possa fazer gravações no Origin e trate FailedPrecondition em todos os pontos em que sua integração presumia que o app havia sido criado.
  • Alterado. O Origin agora concede ao destinatário de um webhook 10 segundos para responder a uma entrega, em vez de cinco. O prazo abrange a resolução de DNS, a conexão, o handshake TLS e o tempo até a resposta, e vale para cada tentativa; uma tentativa que exceder esse prazo conta como erro de transporte e é repetida conforme o cronograma documentado em Tentativas.
  • Alteração incompatível. Os arquivos de Get Repo Tarball envolvem a árvore do repositório em um único diretório de nível superior chamado {ownerSlug}-{repoName}-{shortSha}/, em que shortSha corresponde aos 7 primeiros caracteres hexadecimais do commit resolvido, seguindo o layout do endpoint de tarball do GitHub. Antes, as entradas do arquivo ficavam na raiz do arquivo tar, sem um diretório envolvente. Migração: remova um componente inicial do caminho ao extrair, por exemplo com tar --strip-components=1, em todos os pontos em que sua integração lia entradas da raiz do arquivo tar.
  • Alteração incompatível. Get App passa a exigir namespace:apps:read no namespace proprietário do app, em vez de app:settings:read, o escopo anunciado junto com o endpoint na entrada de 12 de setembro. app:settings:read não autoriza mais nenhuma operação e foi removido do catálogo de escopos; app:settings:write permanece inalterado e continua abrangendo Update App, Add App Signing Key e Revoke App Signing Key. Migração: conceda namespace:apps:read no namespace proprietário do app em todos os pontos em que sua integração usava app:settings:read.
  • Adicionado. List App Installation Repositories aceita filter, uma correspondência de substring que não diferencia maiúsculas de minúsculas, aplicada aos nomes de repositório e aos namespaces de proprietário. Um valor owner/repo com uma única barra compara cada metade com o campo correspondente; espaços em branco no início e no fim são ignorados, e um valor vazio não aplica nenhum filtro. Cada page token carrega o filtro com o qual foi gerado, portanto envie o mesmo filtro ao solicitar as páginas seguintes.
  • Alterado. A especificação OpenAPI não inclui mais format: enum nos esquemas de enum do tipo string. Essa chave não é um formato registrado do OpenAPI nem do JSON Schema, duplicava a lista enum ao lado dela, e geradores que a mapeavam para um tipo nomeado emitiam código que não compilava. Os nomes de esquema, os valores de enum e o JSON transmitido permanecem inalterados; gere novamente qualquer client criado a partir da especificação para obter os tipos corrigidos.
  • Incompatível. Os payloads de repository.check_run.created e repository.check_run.completed não incluem mais um actor no nível do payload. Esse campo repetia o principal da suíte de verificações à qual a execução pertence, que o mesmo payload já entrega como checkSuite.actor e checkRun.actor. Migração: onde sua integração lia o actor de nível superior do payload, leia checkRun.actor, que é sempre igual ao actor da suíte à qual a execução pertence.
  • Incompatível. caseInsensitive e wholeWord em Grep Contents só se aplicam quando literal é true. Uma busca por expressão regular passa a ignorar os dois booleanos, que antes eram respeitados, e uma query contendo apenas (?i) retorna InvalidArgument (HTTP 400). Migração: defina literal para continuar usando os booleanos ou, em uma busca por expressão regular, escreva um (?i) no início e delimitadores de palavra \b diretamente na query.
  • Incompatível. A especificação OpenAPI renomeia o schema de componente Thread para CommentThread. Ele é o schema de resposta de Update Pull Request Thread e o tipo do objeto thread em um comentário de Pull Request. Nomes de campos, caminhos, IDs de operação e o JSON transmitido continuam iguais, então uma integração que lê as respostas diretamente não precisa de nenhuma alteração. Migração: gere novamente qualquer cliente criado a partir da especificação e renomeie o tipo onde o código gerado usava Thread.
  • Adicionado. Add App Installation Repositories adiciona repositórios à seleção de uma instalação existente e retorna a instalação atualizada: POST /v1/origin/namespaces/{namespaceSlug}/installations/{installationId}/repos. O corpo recebe um array obrigatório repoIds, que é combinado com a seleção atual; a gravação nunca altera os escopos da instalação, e uma solicitação cujos repositórios já estejam todos concedidos é concluída com sucesso sem alterar nada. Um repositório fora do namespace, uma instalação que já abrange todos os repositórios do namespace, uma instalação suspensa e uma instalação anterior aos escopos por instalação retornam FailedPrecondition (HTTP 400) e não concedem nada. Requer uma credencial de usuário do Cherri Code com namespace:installations:write e custa 5 pontos. A primeira instalação continua exigindo o consentimento de um administrador do namespace no navegador.
  • Adicionado. Respostas tarifadas de Git over HTTPS incluem X-RateLimit-Limit, X-RateLimit-Remaining e X-RateLimit-Used, com X-RateLimit-Resource definido como git. O Git tem um orçamento próprio, separado do orçamento REST que Limites de taxa documenta como core. Uma solicitação Git que excede o orçamento retorna 429 com Retry-After e X-RateLimit-Reset, e uma solicitação não tarifada não inclui cabeçalhos de limite de taxa.
  • Alterado. Upsert Repository Grant e Upsert Namespace Grant aceitam um principal group pertencente à própria equipe do proprietário do resource, além dos grupos da organização que já aceitavam. Os grupos da própria equipe podem receber concessões mesmo quando essa equipe não está vinculada a uma organização, enquanto um grupo pertencente a outra equipe continua retornando FailedPrecondition (HTTP 400). A página Concessões descreve os tipos de principal.
  • Alteração incompatível. Create Repo exige namespace:repositories:create no lugar de namespace:new_repository:write, que não autoriza mais nada e foi removido do catálogo de escopos. Migração: solicite namespace:repositories:create na credencial de usuário do Cherri Code em todos os pontos em que sua integração solicitava namespace:new_repository:write.
  • Adicionado. Get Pull Request Mergeability informa se um pull request pode ser mergeado e, quando não pode, as condições tipadas que o bloqueiam: GET /v1/origin/repos/{ownerSlug}/{repoName}/pulls/{pullNumber}/mergeability. verdict é mergeable ou blocked, e cada entrada em blockers traz um kind, uma message legível por humanos e o pull request em evaluatedPullRequests ao qual pertence, de modo que o veredito de um pull request em stack abrange todos os pull requests desde a raiz da stack até ele. Uma proteção opcional expectedHeadSha retorna Aborted (HTTP 409 Conflict) quando o head tiver avançado, e um repositório espelhado ou uma stack com mais de 200 pull requests retorna FailedPrecondition (HTTP 400). A operação está disponível em prévia, marcada com x-cursor-visibility: PREVIEW na especificação OpenAPI; portanto, decodifique as respostas tolerando campos e valores de enum desconhecidos e trate um verdict não reconhecido como blocked. Exige repository:pull_requests:read e custa 10 pontos.
  • Adicionado. Grep Contents pesquisa o texto dos arquivos de um repositório em uma ref e retorna as linhas correspondentes: POST /v1/origin/repos/{ownerSlug}/{repoName}:grep. O corpo recebe um query obrigatório, interpretado como expressão regular, a menos que literal esteja definido, além de ref, caseInsensitive, wholeWord, contextBefore e contextAfter (valores acima de 10 são reduzidos para 10), filterPath, as listas de glob includes e excludes (no máximo 20 entradas cada) e maxResults (padrão e máximo de 1000). Cada entrada retornada corresponde a uma linha, e a resposta só está completa quando limitHit é false; não há paginação. Exige repository:contents:read e custa 5 pontos.
  • Adicionado. O status de check-run ganhou um quarto valor, rerequested, e List Check Runs For Commit o aceita como filtro de status. Ele indica uma execução concluída cuja reexecução foi solicitada, mas à qual o app proprietário ainda não respondeu; portanto, trate-a como pendente e exiba-a como queued. Ele aparece em Get Check Run, List Check Runs For Suite, List Check Runs For Commit e Rerequest Check Run. Somente o Origin define esse valor: uma solicitação de Post Check Run ou Batch Upsert Check Runs que o contenha retorna InvalidArgument (HTTP 400).
  • Adicionado. List Pull Requests aceita sortBy, com created (ordem de criação, o padrão) ou updated (hora da última atualização). direction define o sentido da ordenação por sortBy e continua com padrão desc. Um token de página guarda a ordenação com a qual foi gerado, então um token reutilizado com a outra ordenação é rejeitado.
  • Adicionado. List Pull Requests aceita state=merged, que lista apenas pull requests mergeados. closed continua abrangendo todos os pull requests que não estão mais abertos, incluindo os mergeados, então os chamadores existentes continuam vendo os mesmos resultados.
  • Alterado. Rerequest Check Run define o status da execução como rerequested, substituindo a observação de 11 de setembro de que a chamada nunca altera o status nem a conclusion da própria execução. A conclusion e os tempos da execução continuam descrevendo a tentativa substituída; portanto, leia conclusion somente quando status for completed. A execução continua aparecendo como pendente em List Check Runs For Suite e List Check Runs For Commit até que o app responsável responda, o que também limpa rerequestedAt e armazena o status enviado.
  • Alterado. O payload de repository.check_run.rerequested traz checkRun.status como rerequested em vez de completed, e checkRun.conclusion e os tempos continuam descrevendo a tentativa substituída. A migração é a mesma do endpoint: trate cada caso com base em checkRun.status e leia checkRun.conclusion somente quando o status for completed.

Pull requests

  • Alteração incompatível. Create Pull Request e Update Pull Request agora rejeitam um base que não corresponda a um branch existente. Um SHA de commit, um nome de tag ou um branch inexistente retorna InvalidArgument (HTTP 400) e informa a ref totalmente qualificada que o Origin procurou. Antes, a mesma solicitação criava o pull request ou alterava o branch de destino dele. Nesses casos, a ref de merge do pull request nunca podia ser preparada, então o CI nunca a recebia e não era possível mergear o pull request. Migração: passe um nome de branch, na forma curta, como main, ou totalmente qualificada, como refs/heads/main, e altere o destino de todo pull request existente cuja base seja um SHA de commit ou uma tag.

Apps

  • Adicionado. Criar app registra um app pertencente a um namespace: POST /v1/origin/namespaces/{namespaceSlug}/apps. O corpo recebe os campos obrigatórios displayName e publicKey (a chave pública Ed25519 em PEM SPKI com a qual o app assina seus JWTs), além dos opcionais webhookUrl, events, description, websiteUrl, installationRedirectUris e defaultScopes. Os apps são criados como privados, e uma URL de webhook, tipo de evento, URI de redirecionamento ou escopo inválido retorna InvalidArgument (HTTP 400). Requer namespace:apps:create em uma credencial de usuário do Cherri Code e custa 10 pontos.
  • Adicionado. List Namespace Apps lista os apps pertencentes a um namespace, do mais recente para o mais antigo: GET /v1/origin/namespaces/{namespaceSlug}/apps. As entradas trazem apenas metadados de exibição (id, displayName e description); para ler a configuração de webhook de um app, use Get App. Requer namespace:apps:read e custa 1 ponto.
  • Adicionado. Get App retorna a configuração completa de um app pelo id: GET /v1/origin/apps/{appId}. Esta é a leitura de gerenciamento feita pelo publisher; Get Authenticated App continua sendo a leitura que o próprio app faz com seu JWT. Requer app:settings:read e custa 1 ponto.
  • Adicionado. Update App grava a configuração de um app: PATCH /v1/origin/apps/{appId}. displayName, webhookUrl, description e websiteUrl são campos simples, enquanto events, installationRedirectUris e defaultScopes são wrappers de substituição completa, que trocam a lista inteira. Campos omitidos permanecem inalterados, uma requisição que não define nada retorna InvalidArgument (HTTP 400), e enviar webhookUrl como string vazia desativa a entrega e cancela definitivamente as entregas pendentes do app. Requer app:settings:write e custa 5 pontos.
  • Adicionado. Add App Signing Key registra mais uma chave pública Ed25519 para um app: POST /v1/origin/apps/{appId}/signing_keys. A resposta traz o kid a ser usado como ID da chave do JWT, que é o digest SHA-256 em base64url da codificação SPKI DER da chave. Uma chave já registrada retorna AlreadyExists (HTTP 409 Conflict), e uma chave que ultrapasse o limite de chaves ativas do app retorna FailedPrecondition (HTTP 400). Requer app:settings:write e custa 5 pontos.
  • Adicionado. Revoke App Signing Key desativa uma chave de assinatura e responde com 204 No Content: DELETE /v1/origin/apps/{appId}/signing_keys/{kid}. JWTs de app assinados com a chave revogada deixam de autenticar, e revogar a última chave ativa retorna FailedPrecondition (HTTP 400). Requer app:settings:write e custa 5 pontos.
  • Adicionado. As respostas de app trazem namespaceSlug, o slug do namespace ao qual o app pertence, junto com description, websiteUrl e defaultScopes. Esses campos são retornados por Get Authenticated App, Get App, Criar app e Update App.

Concessões

  • Adicionado. List Repository Grants lista os usuários, grupos e grupos da equipe proprietária que têm uma permissão concedida diretamente em um repositório: GET /v1/origin/repos/{ownerSlug}/{repoName}/grants. Permissões herdadas do proprietário do repositório não são incluídas, e um principal que não pode mais ser resolvido é omitido; por isso, uma página pode conter menos concessões do que pageSize. Requer repository:settings:read e custa 1 ponto.
  • Adicionado. Upsert Repository Grant define a permissão que um principal tem diretamente em um repositório: POST /v1/origin/repos/{ownerSlug}/{repoName}/grants. O corpo especifica exatamente um entre user, group ou teamGroup e uma permission igual a read, write ou admin; custom retorna InvalidArgument (HTTP 400), e um principal fora da equipe ou organização do proprietário retorna FailedPrecondition (HTTP 400). Repetir uma concessão que o principal já tem é bem-sucedido e não gera alteração. Requer repository:settings:write e custa 5 pontos.
  • Adicionado. Delete Repository Grant remove a permissão que um principal tem diretamente em um repositório e responde com 204 No Content: DELETE /v1/origin/repos/{ownerSlug}/{repoName}/grants. Permissões herdadas do proprietário não são afetadas, então um grupo da equipe proprietária volta ao padrão definido no nível do proprietário. Remover uma permissão que o principal não tem diretamente é bem-sucedido e não gera alteração. Requer repository:settings:write e custa 5 pontos.
  • Adicionado. List Namespace Grants lista quem recebeu acesso a um proprietário: GET /v1/origin/owners/{ownerSlug}/grants. Cada concessão indica a permissão que confere em todos os repositórios do proprietário, as concessões de admin aparecem primeiro, e concessões feitas em repositórios individuais são excluídas. Requer namespace:settings:read e custa 1 ponto.
  • Adicionado. Upsert Namespace Grant define a permissão que um principal tem diretamente em um proprietário: POST /v1/origin/owners/{ownerSlug}/grants. permission aceita PERMISSION_READ, PERMISSION_CONTRIBUTOR, PERMISSION_WRITE ou PERMISSION_ADMIN, e PERMISSION_CUSTOM retorna InvalidArgument (HTTP 400). Um principal fora da equipe proprietária ou de sua organização, ou uma gravação que deixaria o proprietário sem admin, retorna FailedPrecondition (HTTP 400). Requer namespace:settings:write e custa 5 pontos.
  • Adicionado. Delete Namespace Grant remove a permissão que um principal tem diretamente em um proprietário e responde com 204 No Content: DELETE /v1/origin/owners/{ownerSlug}/grants. Concessões por repositório não são afetadas, e uma remoção que deixaria o proprietário sem admin retorna FailedPrecondition (HTTP 400). Requer namespace:settings:write e custa 5 pontos.

Instalações

Execuções de verificação

  • Alteração incompatível. O payload de repository.check_run.rerequested não inclui mais um rerequestedBy de nível superior. O principal que solicitou a nova execução agora fica na execução de verificação incorporada, como checkRun.rerequestedBy, substituindo a nota de 10 de setembro segundo a qual o payload traz o solicitante junto ao repositório, à suíte e à execução. Migração: leia checkRun.rerequestedBy onde quer que seu destinatário lesse o rerequestedBy do próprio payload.
  • Adicionado. Rerequest Check Run solicita ao app que relatou uma execução de verificação que a execute novamente: POST /v1/origin/repos/{ownerSlug}/{repoName}/check-runs/{checkRunId}/rerequest com corpo vazio. A execução deve estar completed, deve ter isRerequestable, deve ser a tentativa atual para sua key e deve estar no head atual de um pull request aberto; qualquer outro caso retorna FailedPrecondition (HTTP 400), e uma segunda solicitação enquanto outra estiver pendente retorna AlreadyExists (HTTP 409 Conflict). A chamada nunca altera o status nem a conclusion da própria execução. Qualquer principal com repository:contents:write pode solicitar novamente qualquer execução que aceite nova solicitação, independentemente do app que a relatou, e a chamada custa 5 pontos.
  • Adicionado. As execuções de verificação incluem rerequestedBy, o principal que solicitou a nova execução, presente sempre que rerequestedAt estiver definido e limpo junto com ele. Retornado por Obter execução de verificação, List Check Runs For Suite, List Check Runs For Commit, Post execução de verificação, Batch Upsert execução de verificação e Rerequest Check Run.
  • Alterado. rerequestedAt passa a indicar uma nova solicitação pendente, e não mais um registro único. O Origin o limpa quando o app proprietário responde publicando uma nova execução para o mesmo head SHA e key, seja uma nova execução com um novo externalId ou uma atualização da execução solicitada com o mesmo externalId; depois disso, a execução pode ser solicitada novamente. Isso substitui a nota de 10 de setembro segundo a qual uma execução de verificação pode ser solicitada novamente no máximo uma vez; portanto, um destinatário pode receber mais de um evento repository.check_run.rerequested para a mesma execução. Continue eliminando entregas duplicadas pelo id do evento.
  • Alterado. Uma execução de verificação solicitada novamente permanece em List Check Runs For Suite e List Check Runs For Commit e aparece como pendente, com rerequestedAt definido e os status e conclusion anteriores inalterados, em vez de sair das duas listagens até o app responder. Uma verificação obrigatória bloqueia o merge como verificação pendente, e não como ausente. Isso substitui a nota de 10 de setembro segundo a qual a execução sai das listagens até que chegue uma nova tentativa.

Repositórios

  • Adicionado. Update Repo grava as configurações do repositório: PATCH /v1/origin/repos/{ownerSlug}/{repoName}. O corpo aceita os campos opcionais defaultBranch, allowMergeCommit, allowSquashMerge, deleteBranchOnMerge e visibility, e os campos omitidos permanecem inalterados. allowMergeCommit e allowSquashMerge devem ser enviados juntos, com pelo menos um deles como true; defaultBranch e deleteBranchOnMerge retornam FailedPrecondition (HTTP 400) em um repositório que recebe dados de uma fonte upstream; e uma requisição que não define nada retorna InvalidArgument (HTTP 400). Os grupos são aplicados em uma ordem fixa, e não de forma atômica, portanto, se um grupo for rejeitado, os grupos anteriores a ele permanecem aplicados. Requer repository:settings:write e custa 5 pontos.
  • Adicionado. Transition Repo Mirror inicia uma alteração na direção do espelhamento e retorna o job que a acompanha: POST /v1/origin/repos/{ownerSlug}/{repoName}/mirror:transition. O corpo exige um transition com valor initial_to_inbound, inbound_to_outbound ou outbound_to_inbound, e o repositório permanece com status de espelhamento em transição enquanto o job é executado. Um repositório que não esteja no estado inicial esperado pela transição, ou que já tenha um job ativo, retorna FailedPrecondition (HTTP 400). Requer repository:mirror:write em uma credencial de usuário do Cherri Code que também administre o repositório na fonte upstream do espelhamento, e custa 10 pontos.
  • Adicionado. Force Repo Mirror Cutover transfere um repositório para sua fonte upstream sem enviar de volta o estado divergente: POST /v1/origin/repos/{ownerSlug}/{repoName}/mirror:forceCutover com corpo vazio. A fonte é adotada como fonte da verdade no estado em que se encontra, e as refs que existem apenas no Origin são salvas em um snapshot e abandonadas. A operação só é aceita para um repositório com status outbound ou travado em uma transição de outbound para inbound cujo job ativo informe requires_attention; nesse caso, a transferência forçada substitui esse job. Requer repository:mirror:write e custa 10 pontos.
  • Adicionado. Detach Repo Mirror desconecta permanentemente um repositório espelhado da sua fonte upstream e responde 204 No Content: DELETE /v1/origin/repos/{ownerSlug}/{repoName}/mirror. O repositório mantém seu conteúdo e se torna um repositório nativo, a sincronização é interrompida em ambas as direções e a credencial de deploy do espelhamento é excluída. Desvincular um repositório já desvinculado é bem-sucedido, mas não tem efeito, enquanto um repositório que nunca teve espelhamento retorna FailedPrecondition (HTTP 400). Requer repository:mirror:delete e custa 5 pontos.
  • Adicionado. Get Mirror Transition Job retorna um job de transição pelo id: GET /v1/origin/repos/{ownerSlug}/{repoName}/mirror/transition-jobs/{jobId}. Um job informa seu transition, um status com valor queued, running, succeeded, failed_rolled_back, requires_attention ou superseded, um attemptCount e, em caso de falha, lastErrorCode e lastErrorMessage. A string phase é um detalhe de exibição que ganha novos valores à medida que o processo de transição evolui, então consulte status periodicamente para verificar a conclusão em vez de se basear em phase. Requer repository:metadata:read e custa 1 ponto.
  • Adicionado. Get Active Mirror Transition Job retorna o job de transição em andamento do repositório e o último job já finalizado: GET /v1/origin/repos/{ownerSlug}/{repoName}/mirror/transition-jobs:active. Tanto activeJob quanto lastJob são opcionais, então um repositório que nunca passou por transição retorna um objeto vazio; consultar periodicamente até que activeJob desapareça e depois ler lastJob é o que permite distinguir uma transição concluída de uma que nunca foi executada. Requer repository:metadata:read e custa 1 ponto.
  • Alterado. As referências dos endpoints de estado de espelhamento foram movidas para a API de migração do Origin. Os contratos HTTP não mudaram, e as âncoras anteriores da API Origin redirecionam para a nova referência.
  • Adicionado. Merge Pull Request aceita um mergeMethod opcional com valor merge ou squash, que define se o pull request entra como um merge commit ou como um único commit de squash. Um método que o repositório não permite é rejeitado com FailedPrecondition (HTTP 400), e qualquer outro valor, incluindo rebase, é rejeitado com InvalidArgument (HTTP 400). Omita-o para manter o comportamento anterior: um merge commit quando o repositório permite; caso contrário, um squash; e um squash quando a branch base exige histórico linear.
  • Adicionado. Os payloads de repositório incluem visibility, que pode ser internal ou private, além dos booleanos allowMergeCommit, allowSquashMerge e deleteBranchOnMerge. Os quatro campos são somente leitura e são retornados por Get Repo, Criar repositório, List Repos e List App Installation Repositories.
  • Adicionado. As execuções de verificação incluem isRerequestable, em que o app que reporta a execução declara que ela pode ser executada novamente, e rerequestedAt, o timestamp da nova solicitação. Envie isRerequestable em Post execução de verificação e Batch Upsert execução de verificação; ambos os campos são retornados nessas operações e em Obter execução de verificação, List Check Runs For Suite e List Check Runs For Commit. Ao declarar uma execução como re-solicitável, seu app se compromete a responder a cada nova solicitação publicando uma nova execução para o mesmo SHA de head e key.
  • Adicionado. repository.check_run.rerequested é entregue quando uma execução de verificação concluída é solicitada novamente e chega apenas ao app dono da execução, e não a todos os inscritos no repositório. Seu payload inclui o repositório, a suíte de verificações, a execução de verificação marcada e rerequestedBy, mas não traz contexto de pull request; portanto, identifique o pull request a partir de checkRun.sha. A inscrição exige repository:checks:read. Uma execução de verificação só pode ser solicitada novamente uma vez, então elimine reentregas duplicadas usando o id do evento.
  • Adicionado. Todo schema de webhook payload na especificação OpenAPI inclui uma extensão x-origin-webhook-events que indica os eventos com os quais ele é entregue, além de um payload de exemplo selecionado como example do schema. A nova referência de payloads de eventos documenta os campos e o payload de exemplo de cada payload e é gerada a partir desses schemas, no mesmo layout da referência de endpoints.
  • Alterado. Uma execução de verificação solicitada novamente deixa de aparecer em List Check Runs For Suite e List Check Runs For Commit até que o app dono dela publique uma nova tentativa ou atualize a existente com um externalUpdatedAt mais recente. Com isso, uma verificação obrigatória aparece como ausente e bloqueia o merge enquanto a nova solicitação estiver pendente. Para ler a execução excluída, use o id dela com Obter execução de verificação.
  • Alteração incompatível. Uma âncora inline cujo intervalo de linhas ultrapassa o fim do arquivo agora é rejeitada com InvalidArgument (HTTP 400) em Create Pull Request Comment e Create Pull Request Review. O intervalo continua sem se restringir aos hunks do diff e é validado com base no arquivo como ele existe no lado ancorado: left o lê no commit base e right, no head. O erro informa a quantidade de linhas do arquivo. Em uma revisão, basta uma âncora fora do intervalo para que toda a solicitação falhe e nada seja publicado. Migração: antes de gravar, limite inline.startLine e inline.endLine à quantidade de linhas do lado ancorado, obtendo esse valor por meio de Get Contents quando a âncora estiver fora dos hunks do diff.
  • Adicionado. Create Git Ref cria uma branch em um commit existente: POST /v1/origin/repos/{ownerSlug}/{repoName}/git/refs. Recebe ref como refs/heads/<branch> ou heads/<branch> e sha como o SHA hex completo de um commit no repositório; tags e outros namespaces de referência retornam InvalidArgument (HTTP 400). Criar uma branch que já aponta para sha retorna a referência existente, e criar uma branch que já existe em outro commit retorna AlreadyExists (HTTP 409 Conflict). Requer repository:contents:write e custa 5 pontos.
  • Adicionado. Create Commit From Files faz commit de alterações de arquivo inline em uma branch e a avança: POST /v1/origin/repos/{ownerSlug}/{repoName}/git/commits:createFromFiles. Cada entrada de files[] define exatamente um entre content (com encoding utf-8 ou base64 e mode file, executable ou symlink) e delete, e expectedHeadSha deve corresponder à ponta da branch, que se torna o parent do novo commit. A resposta retorna sha, treeSha e previousHeadSha. Cada solicitação comporta no máximo 1.000 alterações de arquivo, 8 MiB por arquivo e 32 MiB de conteúdo no total. Requer repository:contents:write e custa 10 pontos.
  • Alterado. A entrega de webhook agora faz sete novas tentativas após uma falha de envio, em vez de seis, e a primeira nova tentativa ocorre 5 segundos após a falha, e não mais 30 segundos. A sequência completa é de 5 segundos, 30 segundos, 1 minuto, 2 minutos, 4 minutos e 8 minutos; assim, um destinatário que fique fora do ar durante todo o período recebe um POST a mais praticamente na mesma janela de 16 minutos. Desduplique a tentativa extra pelo webhook-id, da mesma forma que você faz com as demais.
  • Alteração incompatível. Os metadados de app não incluem mais slug. O campo foi removido da resposta de Get Authenticated App, de todos os atores de app retornados pelas operações de check, pull request, revisão e comentário (actor.app, author.app e dismissal.dismissedBy.app), do objeto app nos cinco payloads de webhook installation.* e do payload de Ping Webhook. Isso substitui a nota de 2 de setembro, segundo a qual os atores de app incluem displayName junto com id e slug. Antes, era garantido que um ator de app incluísse slug; agora ele inclui id e o campo opcional displayName. Migração: identifique apps por id e rotule-os com displayName em todos os pontos em que sua integração lia slug.
  • Adicionado. List Pull Request Comments aceita um parâmetro de consulta opcional threadIds, que restringe a listagem aos comentários dessas threads. Assim, você pode ler uma única thread sem paginar todo o histórico de comentários de um pull request. Duplicatas são ignoradas, então o limite de 20 se aplica a IDs distintos; uma lista maior ou um ID vazio retorna InvalidArgument (HTTP 400). Os page tokens incorporam o conjunto com o qual foram gerados, então reinicie a paginação sempre que o filtro mudar.
  • Alterado. O filtro author em List Pull Requests agora também aceita o endereço de email exato de um usuário, sem diferenciar maiúsculas de minúsculas, além dos IDs de ator user_…, app_… e sa_… que já aceitava. Um email que não corresponde a um único usuário retorna uma lista vazia em vez de um erro; antes, um email retornava InvalidArgument (HTTP 400). Apps e contas de serviço não têm identidade de email, então só é possível selecionar autores que sejam usuários dessa forma, e os IDs de ator continuam sendo a identidade retornada nessas respostas.
  • Adicionado. List Check Runs For Commit aceita os parâmetros de consulta opcionais checkName e status. checkName corresponde exatamente ao name de uma execução de verificação, e status aceita queued, in_progress ou completed; qualquer outro valor retorna InvalidArgument (HTTP 400). Os dois filtros são aplicados após o agrupamento pela tentativa mais recente. Assim, uma execução é filtrada pelo status da sua tentativa mais recente, e um filtro nunca traz de volta uma tentativa substituída. Os page tokens incorporam os filtros com os quais foram emitidos, então reinicie a paginação quando um filtro mudar.
  • Adicionado. List Pull Request Comments aceita os parâmetros de consulta opcionais since e until, que definem limites inclusivos para o horário de criação do comentário no formato de timestamps RFC 3339, como 2026-08-01T00:00:00Z. Um timestamp malformado retorna InvalidArgument (HTTP 400). Os page tokens incorporam os limites com os quais foram emitidos, então reinicie a paginação quando um limite mudar. Use since para acompanhar novos comentários em vez de paginar novamente todo o histórico de comentários de um pull request.
  • Alterado. Quando os escopos obrigatórios de uma operação vêm da própria credencial, e não de uma concessão da instalação, a extensão x-origin-scopes dessa operação é marcada com ambient: true na especificação OpenAPI publicada. Nove operações têm essa flag, entre elas Get Authenticated App, Criar token de acesso da instalação e List App Installation Repositories. As strings de escopo continuam na extensão, para que as respostas 403 ainda as indiquem, e o tratamento de solicitações não muda. Consulte a flag para distinguir uma operação que exige apenas autenticação de uma que precisa de um escopo aprovado na instalação.
  • Alteração incompatível. List Check Suites For Commit, List Check Runs For Commit e List Check Runs For Suite retornam apenas a tentativa mais recente de cada verificação e omitem as tentativas substituídas, em linha com o que o merge gate e as visualizações de CI do produto já exibiam. Uma suíte é consolidada na sua tentativa mais recente por actor responsável pelo relatório e chave de suíte, e uma execução é consolidada na sua tentativa mais recente por chave de execução dentro de uma suíte. Assim, uma execução com falha e sua nova tentativa bem-sucedida não aparecem mais juntas. totalSize e os tokens de página consideram o conjunto consolidado. Migração: para ler uma tentativa substituída, use o id dela em Get Check Run ou Get Check Suite, que continuam acessando todas as tentativas armazenadas.
  • Adicionado. Create Pull Request Comment aceita uma âncora file que abre uma thread de comentários em um arquivo inteiro no diff da versão da pull request. Ela contém apenas file.path: o Origin deduz o lado a partir do tipo de alteração do arquivo (a versão base para um arquivo excluído e a versão head nos demais casos) e o retorna em thread.side. Envie o caminho excluído no caso de uma exclusão e o caminho head em qualquer outra alteração; um caminho fora do diff ou o caminho original de um arquivo renomeado (anterior à renomeação) retorna InvalidArgument (HTTP 400). file, inline e threadId são mutuamente exclusivos. Create Pull Request Review aceita a mesma âncora como comments[].file.
  • Adicionado. Actors públicos de usuário agora incluem displayName e handle, além de id e email. displayName é o nome e o sobrenome da conta separados por um espaço, o mesmo nome exibido pelo produto, e é omitido quando a conta não tem nome. handle é o handle de perfil reivindicado, sem o prefixo @, e só aparece enquanto esse perfil estiver visível publicamente. Ambos aparecem onde quer que um actor de usuário apareça, incluindo autores de pull requests e comentários, actors de execuções de verificação e de suítes, dispensas de revisão, revisores solicitados, o installedBy de uma instalação e os webhook payloads correspondentes. O recibo de instalação inclui displayName, mas nunca handle.
  • Adicionado. Actors públicos de app agora incluem o displayName registrado do app, além de id e slug, e o objeto app nos cinco webhook payloads installation.* também passa a incluí-lo. Ele é omitido quando não é possível resolver o app e no actor gerenciado próprio do Cherri Code.
  • Alterado. Solicitar um escopo :write também concede o escopo :read correspondente. Assim, uma instalação que solicita repository:labels:write recebe também repository:labels:read. Isso vale quando um app é instalado, quando uma instalação é pré-visualizada e quando um token de acesso da instalação restringe seus escopos; além disso, uma credencial existente somente de gravação agora permite a leitura correspondente. Escopos de leitura continuam sem conceder gravação.
  • Adicionado. repository.deleted é entregue quando um repositório é excluído, seja pela exclusão de um repositório nativo ou de saída no produto, seja pela interrupção da sincronização em um espelho de entrada. O payload traz uma referência repository e deletedAt em vez de um snapshot, porque um repositório excluído não é mais resolvido pela API. A assinatura exige repository:metadata:read. Diferentemente de repository.pushed, este evento é entregue para repositórios espelhados do GitHub, já que interromper a sincronização exclui apenas o repositório do lado do Cherri Code, e o GitHub não envia nada nesse caso. Excluir novamente um repositório já excluído não emite nenhum evento.
  • Adicionado. repository.metadata.updated é entregue quando a branch padrão de um repositório é alterada, incluindo gravações feitas pelas configurações e pela API, um espelho de entrada que acompanha uma renomeação no upstream e a reconciliação do trunk no primeiro push. O payload traz o snapshot completo de repository após a gravação, sem delta e sem o ator que fez a atualização; portanto, compare snapshots sucessivos ou busque o repositório novamente para ver o que mudou. A assinatura exige repository:metadata:read.
  • Adicionado. Os usuários solicitados como revisores agora trazem um email junto com o id. Ele aparece em List Pull Request Requested Reviewers e Request Pull Request Reviewers, e na entrada reviewer.user dos webhooks pull_request.reviewer.added, pull_request.reviewer.removed e pull_request.reviewer.rerequested. O valor é o endereço de email da conta e fica vazio quando a conta não tem um. Antes, esses pontos identificavam o usuário apenas pelo id.
  • Alterado. As respostas REST passam a incluir os campos com valor padrão em vez de omiti-los; assim, um booleano false, um número 0, uma string vazia e um array vazio estão presentes em todos os corpos de resposta. Um pull request que não é rascunho, retornado por Get Pull Request, informa draft como false em vez de omiti-lo, e uma lista vazia retorna [] em vez de não retornar nada. Campos que o contrato marca como opcionais, como submitted_at e dismissal, continuam ausentes quando não definidos. Onde sua integração tratava uma chave ausente como valor padrão, passe a ler o próprio valor. Isso segue a forma como os payloads de webhook sempre foram serializados.
  • Alterado. Cada operação na especificação OpenAPI publicada tem um operationId exclusivo. Quando uma operação atende a dois formatos de URL, o segundo formato recebe o sufixo _2: OriginService_GetRepoTarball_2 para GET …/tarball/{ref} e OriginService_ListMatchingGitRefs_2 para GET …/git/matching-refs. Os dois formatos de URL e o tratamento das solicitações não mudaram; portanto, gere novamente qualquer cliente criado a partir da especificação para obter os métodos renomeados.
  • Alterado. installation.updated também é entregue quando o namespace do proprietário é renomeado, uma vez para cada instalação que ainda pertence ao namespace. O evento traz o novo slug do namespace, junto com os escopos atuais e a seleção de repositórios dessa instalação.
  • Alterado. Todas as operações da especificação OpenAPI publicada incluem uma extensão x-origin-scopes que indica o escopo exigido pela operação e as credenciais aceitas. scopes contém o escopo exigido, e tokenTypes contém os tipos de credencial aceitos: app para um JWT do app, installation para um token de acesso da instalação e user para uma credencial de usuário. Tipos de credencial rejeitados pela operação ficam ausentes de tokenTypes, e Consultar limite de taxa é a única operação que não exige escopo. A extensão também substituiu as frases sobre escopo que constavam nas descrições de Create Label, Update Label e Delete Label. A autorização não mudou: a extensão apenas publica os escopos que o Origin já aplicava.
  • Adicionado. List Pull Request Requested Reviewers retorna os usuários e grupos cuja revisão está pendente em uma pull request: GET /v1/origin/repos/{ownerSlug}/{repoName}/pulls/{pullNumber}/requested_reviewers. Uma solicitação direta é removida quando esse usuário envia uma revisão, e uma solicitação de grupo é removida quando qualquer membro atual do grupo envia uma revisão. Já uma revisão em rascunho não enviada mantém a solicitação pendente. Os revisores são retornados como ids, e a leitura deles requer repository:pull_requests:reviews:read.
  • Adicionado. Request Pull Request Reviewers solicita revisões de usuários e grupos e retorna os revisores solicitados: POST /v1/origin/repos/{ownerSlug}/{repoName}/pulls/{pullNumber}/requested_reviewers. Identifique cada revisor pelo id público user_…, e-mail, id grp_… ou slug do grupo. Nomes de exibição não são resolvidos, um identificador desconhecido ou ambíguo retorna InvalidArgument (HTTP 400), e um revisor que não é candidato para o repositório retorna PermissionDenied (HTTP 403). Solicitar novamente um revisor já solicitado renova a solicitação, de modo que um revisor que já havia enviado uma revisão volta a aparecer como pendente. Requer repository:pull_requests:reviews:write.
  • Adicionado. Remove Pull Request Requested Reviewers remove solicitações de revisão pendentes e retorna 204 com corpo vazio: DELETE /v1/origin/repos/{ownerSlug}/{repoName}/pulls/{pullNumber}/requested_reviewers. Remover um revisor que não está solicitado no momento não tem efeito, e um public id estável continua sendo resolvido mesmo depois que esse revisor sai da lista de candidatos do repositório, o que permite remover solicitações obsoletas. Requer repository:pull_requests:reviews:write.
  • Adicionado. Update Pull Request Thread resolve ou reabre uma thread de comentários de pull request e retorna seu estado atualizado: PATCH /v1/origin/repos/{ownerSlug}/{repoName}/pulls/threads/{threadId}. Envie resolved como true para resolver ou false para reabrir. Ambas as operações são idempotentes, responder a uma thread resolvida não a reabre, e uma thread armazenada em outro repositório retorna 404. Requer repository:pull_requests:reviews:write.
  • Adicionado. Comentários de pull request agora trazem a thread completa em vez de apenas o id da thread. thread passou a incluir a version à qual foi vinculada, com os SHAs de head e base, o path, side, startLine e endLine da âncora de diff da thread, resolvedAt e os próprios createdAt e updatedAt da thread. Retornado por List Pull Request Comments, Get Pull Request Comment e Update Pull Request Comment. thread.id não mudou, então agrupar comentários por ele continua funcionando.
  • Adicionado. Create Pull Request Comment aceita uma âncora inline, composta por path, side, startLine e um endLine opcional, que abre uma thread ancorada em uma linha no diff de uma versão da pull request, além de um versionNumber que indica a versão à qual vincular o comentário e, por padrão, corresponde à mais recente no momento da chamada. O path deve fazer parte do diff dessa versão, em um lado no qual o arquivo tenha conteúdo. Qualquer linha de um arquivo alterado pode servir de âncora, não apenas linhas dentro de um hunk do diff, e uma âncora inválida retorna InvalidArgument (HTTP 400) em vez de virar um comentário de discussão geral. inline e threadId são mutuamente exclusivos, assim como threadId e versionNumber.
  • Adicionado. Create Pull Request Review aceita uma matriz comments, com no máximo 50 itens por solicitação, que publica uma revisão junto com seus comentários em uma única chamada atômica. Cada item contém um body e os mesmos destinos de Create Pull Request Comment: uma âncora inline no diff da versão revisada, uma resposta threadId ou nenhum dos dois, para criar uma nova thread de discussão geral. Todas as âncoras são validadas antes de qualquer gravação, então basta uma âncora inválida para que a solicitação inteira falhe com InvalidArgument (HTTP 400), sem publicar nada. A operação não tem chave de idempotência, então consulte List Pull Request Reviews antes de tentar novamente após uma falha ambígua. Uma solicitação sem comments continua funcionando como antes.
  • Adicionado. pull_request.comment.created inclui a âncora de diff da thread no comentário que abriu a thread, para que um destinatário possa materializar a thread sem precisar de uma leitura adicional. comment.thread contém os campos version, path, side, startLine e endLine aos quais o comentário se refere; uma resposta inclui apenas comment.thread.id, e o estado de resolução não faz parte do evento. Comentários registrados com uma revisão por meio de Create Pull Request Review não emitem nada até que a revisão seja enviada; a partir daí, cada um emite seu próprio evento.
  • Adicionado. Get Repo Tarball baixa um arquivo tar compactado com gzip da árvore de um repositório: GET /v1/origin/repos/{ownerSlug}/{repoName}/tarball/{ref}. A primeira solicitação para um commit resolvido transmite application/gzip como corpo da resposta; solicitações posteriores para o mesmo commit retornam 302 com uma URL de download assinada em Location, válida por 15 minutos. As entradas do arquivo ficam na raiz do arquivo tar, sem diretório de nível superior; um repositório vazio retorna ABORTED (HTTP 409 Conflict); e baixar um arquivo requer repository:contents:read.
  • Adicionado. Listar arquivos de comparação lista os arquivos alterados em uma comparação, ou seja, o diff de head em relação à base de merge de base e head: GET /v1/origin/repos/{ownerSlug}/{repoName}/compare/{basehead}/files. Os resultados são paginados, com 30 arquivos por página por padrão e no máximo 100, e cada arquivo tem o mesmo formato retornado por List Commit Files. Uma comparação identical ou behind retorna uma lista vazia, históricos sem relação retornam 404, e uma comparação cujos commits mudam durante a paginação rejeita o token de página com InvalidArgument (HTTP 400), para que a listagem recomece da primeira página. A leitura de arquivos de comparação requer repository:contents:read.
  • Adicionado. O endpoint de chaves de assinatura envia Cache-Control: public, max-age=600, stale-if-error=600. Reutilize um JWKS em cache por 10 minutos e depois atualize; se uma atualização falhar, mantenha as últimas chaves válidas por no máximo mais 10 minutos antes de falhar a verificação. Atualize ao receber uma assinatura que nenhuma chave ativa consiga verificar, para que um ID de chave desativado seja descartado.
  • Alterado. Uma check run ainda in_progress quando seu deadlineAt expira é concluída com a conclusão timed_out e entrega repository.check_run.completed, substituindo a nota de 27 de agosto de que um prazo não altera o status de uma execução. A expiração ocorre por meio de uma varredura periódica, e não de um temporizador por execução, então uma execução pode ultrapassar brevemente o prazo. Uma execução queued nunca expira, assim como uma execução sem deadlineAt, e o Origin mantém o externalUpdatedAt da execução para que uma conclusão posterior do seu provedor possa sobrescrever a conclusão timed_out.
  • Alterado. repository.pushed não é mais entregue para repositórios que o Origin espelha do GitHub. O GitHub é responsável por esses pushes e envia seus próprios webhooks de push, então a entrega do Origin os duplicava. Pushes para repositórios Origin nativos e para espelhos de saída continuam sendo entregues normalmente, e o estado do espelho não afeta nenhum outro evento.
  • Alterado. Create Pull Request agora rejeita um head sem histórico em comum com base com InvalidArgument (HTTP 400) e não cria nada, em vez de retornar o 404 gerado pela comparação subjacente.
  • Alterado. Um push que deixa o head de um pull request aberto sem histórico em comum com sua base fecha o pull request e entrega pull_request.closed. Um push relacionado posterior não o reabre.
  • Alterado. Cada operação na especificação OpenAPI documenta os códigos de resposta que ela pode retornar, em vez de listar 400, 401, 403 e 429 de forma uniforme em todas as operações: 404 em todo caminho parametrizado, 409 onde um handler reporta conflito, 202 em Batch Redeliver Webhook Deliveries e Sync Mirror, e conjuntos menores em Get Rate Limit e Get Authenticated App. O schema Status descreve o envelope de erro que o Origin retorna, inclusive o fato de que um 404 nunca distingue um recurso inexistente de um inacessível, e toda operação inclui um exemplo de solicitação e de resposta. O tratamento de solicitações não mudou; gere novamente qualquer cliente criado a partir da especificação para obter os novos modelos de resposta.
  • Adicionado. Execuções de verificação aceitam e retornam um timestamp deadlineAt opcional. Envie-o no corpo da execução em Post Check Run ou Batch Upsert Check Runs e leia-o em Get Check Run, List Check Runs For Suite e List Check Runs For Commit. O Origin limpa o prazo assim que a execução chega a completed, mantém o valor armazenado quando uma atualização omite o campo e rejeita prazos a mais de 24 horas no futuro com InvalidArgument (HTTP 400), em vez de ajustá-los ao limite. Quando o prazo expira, o status da execução não muda.
  • Alterado. A especificação OpenAPI publicada declara https://api.cursor.com como servidor e um esquema de segurança HTTP bearer bearerAuth, para que um client gerado a partir do documento já reconheça a base URL e o requisito Authorization: Bearer.
  • Alterado. Os parâmetros de caminho do OpenAPI agora têm os mesmos nomes usados nas URLs. As vinculações geradas identifier.ownerSlug e identifier.name passaram a ser ownerSlug e repoName em todas as 55 operações com escopo de repositório, o que permite que geradores OpenAPI padrão consumam o documento. As URLs e o comportamento das solicitações não mudaram; gere novamente qualquer client criado a partir da especificação para adotar os novos nomes de parâmetros.
  • Alterado. Os enums publicados não listam mais suas entradas de valor zero *_UNSPECIFIED, como RULESET_ENFORCEMENT_UNSPECIFIED em Create Ruleset e PULL_REQUEST_REVIEW_VERDICT_UNSPECIFIED em Create Pull Request Review. O Origin nunca aceitou nem retornou esses valores, portanto solicitações e respostas não mudaram.
  • Alterado. Todas as operações da especificação documentam respostas 400, 401, 403 e 429 com o corpo google.rpc.Status, em vez de apenas a resposta genérica default. Consulte Erros para ver o corpo e a lista completa de status.
  • Alteração incompatível. Os payloads de webhook de revisores para pull_request.reviewer.added, pull_request.reviewer.removed e pull_request.reviewer.rerequested substituem o par reviewer.kind e reviewer.id por um revisor tipado, em que exatamente um entre reviewer.user e reviewer.group está presente. Migração: leia reviewer.user.id onde você lia reviewer.id com reviewer.kind igual a user, e reviewer.group.id onde reviewer.kind era group.
  • Adicionado. List Labels retorna as definições de rótulos de um repositório, ordenadas por nome: GET /v1/origin/repos/{ownerSlug}/{repoName}/labels. A leitura de rótulos exige o novo escopo repository:labels:read. Os resultados são paginados, com 30 rótulos por página por padrão e no máximo 100.
  • Adicionado. Create Label define um rótulo em um repositório e o retorna: POST /v1/origin/repos/{ownerSlug}/{repoName}/labels. Toda gravação de rótulo exige o novo escopo repository:labels:write. name é limitado a 50 caracteres e description a 255, color deve ter seis caracteres hexadecimais sem # inicial, e um nome já usado por outro rótulo do repositório é rejeitado com AlreadyExists (HTTP 409 Conflict).
  • Adicionado. Get Label retorna um rótulo do repositório pelo nome: GET /v1/origin/repos/{ownerSlug}/{repoName}/labels/{labelName}. Um nome inexistente retorna 404.
  • Adicionado. Delete Label exclui um rótulo do repositório pelo nome e retorna 204: DELETE /v1/origin/repos/{ownerSlug}/{repoName}/labels/{labelName}. Excluir um rótulo também o remove de todos os pull requests aos quais ele estava atribuído.
  • Adicionado. Update Label altera o nome, a cor ou a descrição de um rótulo, identificando-o pelo nome atual: PATCH /v1/origin/repos/{ownerSlug}/{repoName}/labels/{labelName}. Campos omitidos permanecem inalterados, e renomear para um nome já usado por outro rótulo é rejeitado com AlreadyExists (HTTP 409 Conflict).
  • Adicionado. List Check Run Annotations retorna as anotações de uma execução de verificação em ordem crescente de ID, que também é a ordem de criação: GET /v1/origin/repos/{ownerSlug}/{repoName}/check-runs/{checkRunId}/annotations. A leitura exige repository:checks:read. Os resultados são paginados, com 30 anotações por página por padrão e no máximo 100.
  • Adicionado. Create Check Run Annotations acrescenta de 1 a 25 anotações a uma execução de verificação em um único lote atômico e as retorna: POST /v1/origin/repos/{ownerSlug}/{repoName}/check-runs/{checkRunId}/annotations. O acréscimo exige repository:checks:write. Uma execução de verificação comporta no máximo 100 anotações, e um lote que ultrapasse esse limite é rejeitado com ResourceExhausted (HTTP 429) sem gravar nada. A operação só permite acréscimos e não é idempotente, portanto uma nova tentativa após uma falha ambígua pode gerar duplicatas.
  • Adicionado. List Pull Requests aceita mais cinco parâmetros de consulta: author, um ID público de ator exatamente como a resposta o retorna em pullRequests[].author.user.id, pullRequests[].author.app.id ou pullRequests[].author.serviceAccount.id; base, um filtro exato de branch base que aceita um nome curto ou uma ref totalmente qualificada; direction, desc para os mais recentes primeiro (o padrão) ou asc para os mais antigos primeiro; e since e until, limites inclusivos em RFC 3339 para a data de criação. Um autor sem pull requests retorna uma lista vazia, e qualquer outro valor inválido retorna InvalidArgument (HTTP 400).
  • Adicionado. pull_request.review.dismissed é entregue quando uma revisão enviada é descartada, seja explicitamente, seja por ter sido substituída por uma decisão mais recente. Ele traz o mesmo formato de payload que pull_request.review.submitted, com review.dismissal preenchido, e a assinatura exige repository:pull_requests:reviews:read.
  • Adicionado. As instalações agora identificam o usuário que instalou o app. installedBy, que contém o ID público user_… e o email desse usuário, é retornado por Get App Installation e List App Installations e acompanha todos os snapshots de webhook installation.*. Nesses snapshots, ele identifica quem fez a instalação original e é omitido quando o registro desse usuário não pode mais ser lido. O recibo de instalação passa a incluir uma declaração installedBy que identifica o usuário que realizou aquela instalação ou novo consentimento. Por isso, após um novo consentimento, os dois valores podem ser diferentes.
  • Adicionado. Ping Webhook envia uma entrega de teste para a URL de webhook configurada no seu app e informa o que o destinatário respondeu: POST /v1/origin/app/webhook/pings. A entrega é assinada como uma entrega de produção, tem webhook-event-type igual a ping e não pertence a nenhuma instalação. O Origin a envia uma única vez, sem novas tentativas, e ela nunca aparece em List Webhook Deliveries. Um app sem URL de webhook configurada é rejeitado com FailedPrecondition (HTTP 400).
  • Adicionado. Respostas de erro trazem o request ID duas vezes: no cabeçalho de resposta X-Request-ID e em uma entrada google.rpc.RequestInfo em details. O Origin repete o x-request-id que você enviou ou gera um quando nenhum é enviado, e inclui a entrada mesmo quando a mensagem é um erro interno opaco. Veja Erros.
  • Alterado. Create Pull Request e Update Pull Request rejeitam um title com mais de 256 caracteres ou um body com mais de 65.536 caracteres, retornando InvalidArgument (HTTP 400). Antes, valores acima desses limites falhavam com um erro interno. Ambos os limites contam code points Unicode, então um caractere astral, como um emoji, conta apenas uma vez.
  • Alterado. As respostas de Sync Mirror sempre trazem synced, com true ou false, de acordo com o HTTP status: 200 quando verdadeiro, 202 quando falso. Antes, o campo era omitido quando falso, e os chamadores precisavam interpretar um campo ausente como false.
  • Alterado. Caminhos sem correspondência em /v1/origin e solicitações que usam o método errado em um caminho conhecido retornam o envelope de erro documentado, em vez de um corpo genérico do router. A mensagem informa o método e o caminho e nunca repete a query string.
  • Alterado. Mergear um pull request agora entrega um webhook repository.pushed para o base ref que o merge avança. Como o próprio Origin realiza esse push, o evento não identifica nenhum autor do push. Antes, atualizações do base ref decorrentes de um merge não eram entregues.
  • Alterado. Criar comentário de Pull Request e Atualizar comentário de Pull Request agora rejeitam um body com mais de 65.536 caracteres, retornando InvalidArgument (HTTP 400). Antes, um corpo acima desse tamanho falhava com um erro interno. O limite considera pontos de código Unicode, então um caractere astral, como um emoji, é contado uma única vez.
  • Adicionado. Delete Ruleset exclui um ruleset do repositório pelo seu ID estável do Origin e retorna 204: DELETE /v1/origin/repos/{ownerSlug}/{repoName}/rulesets/{rulesetId}. Requer repository:rulesets:write. Um ruleset armazenado em outro repositório é tratado como desconhecido, e um rulesetId vazio é rejeitado com InvalidArgument (HTTP 400).
  • Adicionado. Todo endpoint com escopo de repositório identifica um repositório pelo seu ID estável, além do proprietário e nome: envie _ como slug do proprietário e o ID como nome do repositório, como em GET /v1/origin/repos/_/REPO_ID. Obtenha o ID no campo id de Obter repositório. O ID continua válido após uma renomeação, mas não concede nenhuma permissão por si só. Por isso, seu app precisa do mesmo escopo no repositório resolvido, e um ID que ele não consegue acessar retorna o mesmo 404 de um ID inexistente. Criar repositório aceita apenas um slug do proprietário e rejeita _.
  • Alterado. Apps agora acessam repositórios espelhados. Um espelho pode ser selecionado em uma instalação, aparece em List App Installation Repositories e nas matrizes de repositórios do payload do webhook da instalação, pode ser indicado em repositoryIds em Criar token de acesso da instalação e recebe entregas de webhook. Enquanto não se torna um espelho de saída estável, o espelho permanece somente leitura: apenas repository:metadata:read e repository:contents:read se aplicam, e qualquer outro escopo retorna 403 nesse repositório, incluindo git push. Consulte Repositórios espelhados.
  • Alteração incompatível. O parâmetro de consulta recursive em Get Tree é um booleano, e não uma string, então apenas true e 1 percorrem a árvore inteira; qualquer outro valor, incluindo false, 0 e um ?recursive sem valor, lista apenas os filhos imediatos. Migração: envie recursive=true em todos os pontos em que sua integração dependia de qualquer valor não vazio de recursive para ativar a recursão.
  • Alteração incompatível. Os payloads de webhook do ciclo de vida de pull requests omitem os labels atribuídos ao pull request, substituindo o campo anunciado em 20 de agosto de 2026. As respostas REST continuam incluindo esse campo. Migração: leia os rótulos em Get Pull Request ou List Pull Requests em vez de usar o snapshot do webhook.
  • Adicionado. List Rulesets retorna todos os rulesets configurados em um repositório, além de uma referência repository compartilhada: GET /v1/origin/repos/{ownerSlug}/{repoName}/rulesets. Como os rulesets são uma configuração de tamanho limitado, a resposta não é paginada. A leitura de rulesets exige repository:rulesets:read.
  • Adicionado. Create Ruleset armazena um novo ruleset e o retorna com os IDs que o Origin atribui a cada regra e a cada ator de bypass: POST /v1/origin/repos/{ownerSlug}/{repoName}/rulesets. Os dois endpoints de gravação de rulesets exigem repository:rulesets:write.
  • Adicionado. Get Ruleset retorna um único ruleset pelo seu ID estável no Origin: GET /v1/origin/repos/{ownerSlug}/{repoName}/rulesets/{rulesetId}.
  • Adicionado. Update Ruleset substitui integralmente a configuração de um ruleset, incluindo rules e bypassActors: PUT /v1/origin/repos/{ownerSlug}/{repoName}/rulesets/{rulesetId}. Envie todas as regras e todos os atores de bypass que deseja manter, pois as entradas armazenadas são substituídas, e não mescladas.
  • Adicionado. Rulesets incluem id, name, description, enforcement (active, evaluate ou disabled), kind (merge_branch, push_branch, push_tag ou push_repository), os padrões includedRefNames e excludedRefNames (que aceitam globs e os tokens ~ALL e ~DEFAULT_BRANCH), rules e bypassActors. Create Ruleset e Update Ruleset rejeitam com InvalidArgument (HTTP 400) mais de 64 padrões por lista, 20 regras ou 15 atores de bypass.
  • Adicionado. Merge Pull Request aceita um campo opcional expectedHeadSha na solicitação: o SHA completo do commit ao qual o head do pull request deve corresponder. Se o head tiver mudado, o merge é rejeitado com ABORTED (HTTP 409 Conflict) e nada é mergeado; um valor que não seja um SHA completo de commit é rejeitado com InvalidArgument (HTTP 400). Omita o campo para fazer o merge do head atual, seja ele qual for.
  • Adicionado. Referências de proprietário incluem uma string type (team ou user), omitida quando o Origin não consegue resolvê-la. Ela é retornada sempre que aparece um owner ou um target de instalação, incluindo Get Repo, List Repos, List App Installations e a referência de repositório nas respostas de checks e de pull requests.
  • Alteração incompatível. List Pull Request Labels retorna todos os rótulos atribuídos em uma única resposta e não é mais paginado: os parâmetros de consulta pageSize e pageToken e o campo de resposta nextPageToken foram removidos. Migração: remova pageSize e pageToken da solicitação e leia o conjunto completo em labels.
  • Alteração incompatível. Um pull request comporta no máximo 100 rótulos, e Add Pull Request Labels e Set Pull Request Labels rejeitam com FailedPrecondition (HTTP 400) qualquer gravação que ultrapasse esse limite. Migração: mantenha cada pull request com no máximo 100 rótulos, removendo rótulos antes de adicionar novos.
  • Adicionado. Pull requests agora incluem uma matriz labels com os rótulos atribuídos a eles, ordenada por nome e vazia quando não há rótulos atribuídos. Essa matriz é retornada por List Pull Requests, Get Pull Request, Create Pull Request, Update Pull Request e Merge Pull Request, e incluída nos payloads de webhook do ciclo de vida de pull requests.
  • Adicionado. List Pull Request Labels retorna os rótulos atribuídos a um pull request, ordenados por nome: GET /v1/origin/repos/{ownerSlug}/{repoName}/pulls/{pullNumber}/labels. Requer repository:pull_requests:read. Os resultados são paginados, com 30 rótulos por página por padrão e no máximo 100 rótulos por página.
  • Adicionado. Add Pull Request Labels atribui rótulos existentes do repositório a um pull request, sem alterar os rótulos que ele já tem: POST /v1/origin/repos/{ownerSlug}/{repoName}/pulls/{pullNumber}/labels. Todos os endpoints de gravação de rótulos exigem repository:pull_requests:write.
  • Adicionado. Set Pull Request Labels substitui todos os rótulos de um pull request pelos nomes enviados. Uma lista vazia remove todos eles: PUT /v1/origin/repos/{ownerSlug}/{repoName}/pulls/{pullNumber}/labels.
  • Adicionado. Remove Pull Request Label remove um rótulo pelo nome e retorna os rótulos restantes no pull request: DELETE /v1/origin/repos/{ownerSlug}/{repoName}/pulls/{pullNumber}/labels/{labelName}.
  • Adicionado. Remove All Pull Request Labels remove todos os rótulos de um pull request e retorna 204: DELETE /v1/origin/repos/{ownerSlug}/{repoName}/pulls/{pullNumber}/labels.
  • Adicionado. As entradas de rótulo contêm id, name, color (um valor hexadecimal de seis caracteres sem # inicial) e uma description opcional. Elas são retornadas por todos os endpoints de rótulos de pull request.
  • Alterado. O orçamento do limite de taxa do JWT do app aumentou de 600 para 6.000 pontos por minuto, e Criar token de acesso da instalação passou a consumir 1 ponto em vez de 5. Assim, um app pode emitir cerca de 100 tokens de instalação por segundo.
  • Alterado. A elegibilidade de proprietários para Criar repositório e para pushes via Git HTTPS agora inclui os planos Pro Student e Start, além de Pro, Pro+ e Ultra. Os requisitos para proprietários do tipo equipe continuam os mesmos.
  • Alterado. Slugs de proprietários e nomes de repositórios em caminhos de repositório agora são resolvidos sem diferenciar maiúsculas de minúsculas, e as respostas retornam a grafia armazenada, não a que você enviou. Criar repositório rejeita nomes que diferem apenas em maiúsculas/minúsculas de um nome que o proprietário já tem; portanto, compare nomes de repositórios sem diferenciar maiúsculas de minúsculas.
  • Alteração incompatível. O Git via HTTPS rejeita um push com 403 quando o proprietário do repositório não está habilitado para gravação no Origin. Se o proprietário for um usuário, ele precisa ter um plano Pro, Pro+ ou Ultra; se for uma equipe, ela precisa ter um plano de equipe pago ativo, não pode estar no Privacy Mode (legado) e não pode ter o Origin desativado por um admin da equipe. Clone, fetch e pull não são afetados. Migração: trate o 403 no push como uma falha de habilitação do proprietário que não se resolve com uma nova tentativa e confirme o plano do proprietário antes de fazer push em nome dele.
  • Alterado. O primeiro push para um repositório criado com Criar repositório redefine o defaultBranch quando esse push apenas cria branches e nenhuma delas é a branch padrão armazenada: o Origin escolhe a branch criada ou, se o push criar várias e uma delas se chamar main ou master, escolhe essa. Consulte o valor atual em Obter repositório.
  • Alteração incompatível. Criar repositório rejeita solicitações cujo proprietário não esteja apto a fazer gravações no Origin e retorna FailedPrecondition (HTTP 400). Um proprietário do tipo usuário precisa estar em um plano Pro, Pro+ ou Ultra, e um proprietário do tipo equipe precisa ter um plano de equipe pago ativo, não pode estar no Privacy Mode (legado) e não pode ter o Origin desativado por um Admin da equipe. Migração: trate o 400 de Criar repositório como uma falha de elegibilidade do proprietário que não se resolve com uma nova tentativa e confirme o plano do proprietário antes de criar repositórios em nome dele.
  • Alteração incompatível. Os apps perderam o acesso aos repositórios que o Origin espelha do GitHub. Esses repositórios não aparecem mais em List App Installation Repositories, o Criar token de acesso da instalação os rejeita em repositoryIds, e uma solicitação que faça referência a um deles retorna 403 tanto na REST API quanto no Git via HTTPS. Migração: descubra os repositórios por meio de List App Installation Repositories em vez de usar uma lista de repositórios armazenada, e faça a leitura de repositórios vindos do GitHub diretamente no GitHub, e não pela API Origin.
  • Alteração incompatível. O Origin deixou de enviar webhooks para os repositórios que espelha do GitHub, e os payloads de eventos de instalação deixaram de incluir esses repositórios nas matrizes de repositórios selecionados e em repositoriesCount. Migração: obtenha os eventos de repositórios vindos do GitHub diretamente no GitHub e considere a matriz de repositórios do payload de instalação como o conjunto de repositórios que seu app pode acessar.
  • Alteração incompatível. Os payloads de webhook de revisores trazem um ID externo estável em reviewer.id: o ID de usuário codificado (user_…, no mesmo formato da API da organização) quando kind é user, em substituição ao ID de autenticação com escopo do provedor; revisores do tipo grupo mantêm o public id do grupo (grp_…). Afeta pull_request.reviewer.added, pull_request.reviewer.removed e pull_request.reviewer.rerequested. Migração: onde sua integração comparava reviewer.id com IDs de autenticação armazenados, passe a identificar revisores do tipo usuário pelo ID codificado user_….
  • Adicionado. Os apps podem ter até 10 chaves de assinatura Ed25519 ativas, e a verificação de JWT do app aceita tokens assinados com qualquer chave ativa.
  • Adicionado. Sync Mirror sincroniza uma ref de um repositório espelhado a partir da sua fonte upstream: POST /v1/origin/repos/{ownerSlug}/{repoName}:syncMirror. Requer repository:contents:read e retorna 200 quando o alvo da sincronização é atingido ou 202 enquanto a sincronização está pendente.
  • Adicionado. Os redirecionamentos pós-instalação incluem um parâmetro de consulta installation_receipt: um JWT assinado pelo Origin, válido por cinco minutos, que identifica a instalação na declaração sub e replica o state do publisher como uma declaração. Valide-o com o JWKS publicado antes de confiar no callback. Consulte Recibo de instalação.
  • Removido. Os objetos de actor do Origin não incluem mais os campos de nível superior kind e id, concluindo a descontinuação anunciada em 5 de agosto de 2026. Todos os campos actor, author e dismissedBy nas respostas de checks, commits e pull requests são afetados. Migração: leia a variante user, app ou serviceAccount definida no actor.
  • Obsoleto. OriginActor.kind e OriginActor.id. A identidade do ator é uma união discriminada das variantes user, app e serviceAccount. Migração: leia os campos da variante selecionada em vez de kind e id no nível raiz.