Allow GitLab API Token as webhook header

[AlanMasciangelo]

Feature request

Allow GITLAB__PERSONAL_ACCESS_TOKEN to be included as a webhook header rather than loaded from configuration.

Motivation

As someone hosting a central webhook server for others, this would allow the project owner/creator of the webhook to provide and control API access back into their project. Rather than requiring them to add my bot user.

[qodo-merge-for-open-source]

💡 Auto-generated documentation-based answer:

The docs show two supported patterns for GitLab webhook deployments:

• Self-hosted webhook server: You pass the GitLab Personal Access Token via environment/config (e.g., GITLAB__PERSONAL_ACCESS_TOKEN) and set a separate webhook shared secret. The token is not documented as being accepted from incoming webhook request headers.
• Qodo Merge hosted (cloud) flow: you register a PAT and receive a shared secret; the webhook uses that secret for verification.

There’s no documented support for supplying the GitLab PAT in the webhook HTTP headers at runtime. Current setup expects the PAT to be configured on the server (env/secrets) and the webhook uses a shared secret for auth/verification.

If you need this capability, it would be a new feature request. For more precise guidance, we’d need:

• The exact header name/format you propose (e.g., Authorization: Bearer or X-Gitlab-Token: ).
• Whether per-repo/per-group tokens should be dynamically selected from the header, and expected fallback behavior.
• How to handle token rotation and permission scoping securely.

Workarounds today:

• Run separate webhook endpoints or instances per customer/org with their own PAT set via env/secrets.
• For GitLab Cloud with Qodo Merge, use the registration page to bind a PAT to a generated shared secret per org/project.

Relevant Sources:

• https://qodo-merge-docs.qodo.ai//installation/gitlab#run-a-gitlab-webhook-server
• https://qodo-merge-docs.qodo.ai//installation/gitlab#deploy-as-a-lambda-function
• https://qodo-merge-docs.qodo.ai//installation/locally#utilizing-environment-variables
• https://qodo-merge-docs.qodo.ai//installation/qodo_merge#install-qodo-merge-for-gitlab

[mrT23]

Webhooks are created automatically by GitLab.

In any case, even for a custom system, they should not be used to send a direct GitLab API Token - it's insecure.
use enviroment variables

[AlanMasciangelo]

@mrT23 GitLab and many other webhook systems provide a means to set custom headers https://docs.gitlab.com/user/project/integrations/webhooks/#custom-headers which could be used in this case.

I'm not sure why it would be considered insecure, this is a technique I've seen on many other projects where a webhook server needs to authenticate on behalf of the origin webhook event.

[mrT23]

Webhooks can pass an additional secret to validate requests.

https://docs.gitlab.com/user/project/integrations/webhooks/

but never a direct Gitlab access token

[AlanMasciangelo]

They can also pass additional custom headers. For example, I could configure my webhook with a customer header GITLAB_API_TOKEN containing a project access token which gives the necessary permissions for pr-agent. pr-agent could then read that header on all incoming webhooks and if present, use to to authenticate with GitLab.

[mrT23]

You can. But it's an insecure practice.

It's not something that we will enable in pr-agent. But you can implement this change in your local fork