Sobre conteúdo e eventos de webhook
Você pode criar webhooks que subscrevem os eventos listados nesta página. Para limitar o número de solicitações HTTP feitas ao servidor, você deve inscrever apenas os eventos específicos que planeja manipular. Para saber mais, confira Criação de webhooks.
Cada evento de webhook nessa página inclui uma descrição das propriedades de webhook para esse evento. Se o evento tiver várias ações, as propriedades correspondentes a cada ação serão incluídas.
Cada evento está disponível apenas para tipos específicos de webhooks. Por exemplo, um webhook de organização pode se inscrever no evento team, mas um webhook de repositório não pode. A descrição de cada evento de webhook lista a disponibilidade para esse evento. Para saber mais, confira Tipos de webhooks.
A propriedade sender
A maioria das cargas de webhook inclui uma propriedade sender que identifica o usuário que disparou o evento. Às vezes GitHub , não é possível resolver um usuário específico, por exemplo, quando um evento vem de um processo interno em vez de uma pessoa ou quando a ação de gatilho não tem nenhum usuário associado. Para alguns eventos, como check_run e check_suite, isso inclui ações sem push no Git nem ator de API autenticado.
Nesses casos, sender é populado com o usuário ghost, uma conta de espaço reservado cujo login é ghost e cujo id não está vinculado a um usuário real, atual. Não suponha que sender sempre identifique a pessoa que causou um evento, e leve em consideração o usuário ghost em qualquer lógica de segurança ou de negócio que dependa disso.
Limite de carga útil
O conteúdo é limitado a 25 MB. Se um evento gerar um conteúdo maior, o GitHub não entregará conteúdo para esse evento de webhook. Isso pode acontecer, por exemplo, em um evento create, caso muitos branches ou muitas marcas sejam enviados por push de uma só vez. Sugerimos monitorar o tamanho da sua carga para garantir a entrega.
Cabeçalhos de entrega
As cargas HTTP POST que são entregues no endpoint da URL configurada do seu webhook conterão vários cabeçalhos especiais:
X-GitHub-Hook-ID: o identificador exclusivo do webhook.X-GitHub-Event: o nome do evento que disparou a entrega.X-GitHub-Delivery: um GUID (identificador global exclusivo) para identificar o evento.X-Hub-Signature: esse cabeçalho será enviado se o webhook estiver configurado com umsecret. Este é o resumo hexadecimal HMAC do corpo da solicitação, e é gerado por meio da função hash SHA-1 e dosecretcomo akeydo HMAC. OX-Hub-Signatureé fornecido para compatibilidade com integrações existentes. Recomendamos que você use oX-Hub-Signature-256mais seguro em vez disso.X-Hub-Signature-256: esse cabeçalho será enviado se o webhook estiver configurado com umsecret. Este é o resumo hexadecimal HMAC do corpo da solicitação, e é gerado por meio da função hash SHA-256 e dosecretcomo akeydo HMAC. Para saber mais, confira Validação de entregas de webhooks.User-Agent: esse cabeçalho sempre terá o prefixoGitHub-Hookshot/.X-GitHub-Hook-Installation-Target-Type: o tipo de recurso em que o webhook foi criado.X-GitHub-Hook-Installation-Target-ID: o identificador exclusivo do recurso em que o webhook foi criado.
Para ver como cada cabeçalho pode aparecer em um payload de webhook, consulte Exemplo de entrega de webhook.
Exemplo de entrega do webhook
Você pode optar por ter conteúdo entregue no formato JSON (application/json) ou como dados codificados por URL (x-www-form-urlencoded). A seguir está um exemplo de uma solicitação POST de webhook que usa o formato JSON.
> POST /payload HTTP/1.1
> X-GitHub-Delivery: 72d3162e-cc78-11e3-81ab-4c9367dc0958
> X-Hub-Signature: sha1=7d38cdd689735b008b3c702edd92eea23791c5f6
> X-Hub-Signature-256: sha256=d57c68ca6f92289e6987922ff26938930f6e66a2d161ef06abdf1859230aa23c
> User-Agent: GitHub-Hookshot/044aadd
> Content-Type: application/json
> Content-Length: 6615
> X-GitHub-Event: issues
> X-GitHub-Hook-ID: 292430182
> X-GitHub-Hook-Installation-Target-ID: 79929171
> X-GitHub-Hook-Installation-Target-Type: repository
> {
> "action": "opened",
> "issue": {
> "url": "https://api.github.com/repos/octocat/Hello-World/issues/1347",
> "number": 1347,
> ...
> },
> "repository" : {
> "id": 1296269,
> "full_name": "octocat/Hello-World",
> "owner": {
> "login": "octocat",
> "id": 1,
> ...
> },
> ...
> },
> "sender": {
> "login": "octocat",
> "id": 1,
> ...
> }
> }
branch_protection_configuration
This event occurs when there is a change to branch protection configurations for a repository. For more information, see "About protected branches." For information about using the APIs to manage branch protection rules, see "Branch protection rule" in the GraphQL documentation or "Branch protection" in the REST API documentation.
To subscribe to this event, a GitHub App must have at least read-level access for the "Administration" repository permission.
Disponibilidade para branch_protection_configuration
- Repositórios
- Organizações
- Aplicativos GitHub
Objeto da carga do webhook para branch_protection_configuration
All branch protections were disabled for a repository.
| Nome, Tipo, Descrição |
|---|
action string ObrigatórioValor: |
enterprise object An enterprise on GitHub. Webhook payloads contain the |
installation object The GitHub App installation. Webhook payloads contain the |
organization object A GitHub organization. Webhook payloads contain the |
repository object ObrigatórioThe repository on GitHub where the event occurred. Webhook payloads contain the |
sender object ObrigatórioA GitHub user. |
branch_protection_rule
This event occurs when there is activity relating to branch protection rules. For more information, see "About protected branches." For information about the APIs to manage branch protection rules, see the GraphQL documentation or "Branch protection" in the REST API documentation.
To subscribe to this event, a GitHub App must have at least read-level access for the "Administration" repository permission.
Disponibilidade para branch_protection_rule
- Repositórios
- Organizações
- Aplicativos GitHub
Objeto da carga do webhook para branch_protection_rule
A branch protection rule was created.
| Nome, Tipo, Descrição |
|---|
action string ObrigatórioValor: |
enterprise object An enterprise on GitHub. Webhook payloads contain the |
installation object The GitHub App installation. Webhook payloads contain the |
organization object A GitHub organization. Webhook payloads contain the |
repository object ObrigatórioThe repository on GitHub where the event occurred. Webhook payloads contain the |
rule object ObrigatórioThe branch protection rule. Includes a |
Properties of |
sender object ObrigatórioA GitHub user. |
check_run
This event occurs when there is activity relating to a check run. For information about check runs, see "Getting started with the Checks API." For information about the APIs to manage check runs, see the GraphQL API documentation or "Check Runs" in the REST API documentation.
For activity relating to check suites, use the check-suite event.
To subscribe to this event, a GitHub App must have at least read-level access for the "Checks" repository permission. To receive the rerequested and requested_action event types, the app must have at least write-level access for the "Checks" permission. GitHub Apps with write-level access for the "Checks" permission are automatically subscribed to this webhook event.
Repository and organization webhooks only receive payloads for the created and completed event types in repositories.
The API only looks for pushes in the repository where the check run was created. Pushes to a branch in a forked repository are not detected and return an empty pull_requests array and a null value for head_branch.
Disponibilidade para check_run
- Repositórios
- Organizações
- Aplicativos GitHub
Objeto da carga do webhook para check_run
A check run was completed, and a conclusion is available.
| Nome, Tipo, Descrição |
|---|