The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
| Stage | Foundations |
| Maturity | Viable |
| Content Last Reviewed | 2025-04-07 |
Thanks for visiting this category direction page on Webhooks in GitLab. This page belongs to the Import and Integrate group of the Foundations stage and is maintained by the group's Product Manager, Magdalena Frankiewicz (E-mail, Calendly).
This direction page is a work in progress, and everyone can contribute:
Webhooks are a generic way for projects to be integrated with any other service. GitLab's APIs allow other services to reach in to our data, whereas Webhooks proactively send data to another service when certain events happen. These are increasingly important for external vendors, as they offer a key way to integrate with GitLab that doesn't require them building inside our codebase. Webhooks also give users, customers, and partners a more efficient pattern for receiving data triggered based on events, rather than inefficiently polling to see if any new events are available.
While we recognize the importance of robust webhook functionality for enabling integrations and partner ecosystems, the Import and Integrate team has prioritized migration capabilities for FY26 in alignment with GitLab's company objectives. This means that Webhooks will continue to remain in maintenance mode.
For FY26, the Webhooks category will remain in maintenance mode due to the Import and Integrate team's focus on migration capabilities, within Importers category.
We will continue to:
However, active development of new webhook features by the Import and Integrate team is not planned for FY26.
In our long-term vision, we aim to:
Our customers should enjoy learning about and using our webhooks to design creative solutions and intelligent workflows, and be motivated to share GitLab as an example of an incredible third-party developer experience.
To facilitate future contributions and ensure consistency, we've created a comprehensive Webhooks Development Guide containing details on aspects like recommended payload schema, performance considerations, and flow of trigger and execution. Please keep this guide in mind when implementing or reviewing changes to webhooks. This standardized documentation enables teams across different domains to implement their own webhook requirements while maintaining consistency with our established patterns. The guide also facilitates more community contributions by providing clear implementation standards and best practices.
We strongly encourage and welcome community contributions to the Webhooks category. The significant enhancements made in recent releases through community contributions, like introducing changes to webhook self-healing behavior, which reduce manual intervention and improve reliability, demonstrate the value of this collaborative approach.
If you're interested in contributing to Webhooks, please:
Feel free to reach out to the team directly if you need guidance or want feedback on your work by using the ~"group::import and integrate" label on your open merge requests
You can find the most requested improvements in this list of most looked after improvements and the epic gathering webhooks improvements themes.