Webhook endpoints
The endpoints where CI/CD providers deliver events to Prodgator, how each delivery is verified, and what Prodgator answers.
Providers deliver events to Prodgator over HTTPS. For GitHub, GitLab, Bitbucket and Azure DevOps, Prodgator creates the webhook when you connect, so you do not call these endpoints yourself. For Jenkins, your pipeline calls its endpoint. See Connect Jenkins.
Endpoints
| Provider | Endpoint | Verification |
|---|---|---|
| GitHub | : HMAC-SHA256 of the body with the GitHub App's webhook secret | |
| GitLab | equals the connection's secret token | |
| Bitbucket | : and the HMAC-SHA256 of the body with the connection's secret | |
| Azure DevOps | Basic authentication: the connection's secret is the password | |
| Jenkins | : hex HMAC-SHA256 of the body with the connection's secret | |
| AWS | Token from the connection, sent by the EventBridge rule |
The provider is detected from its headers (, , , ). A connection ID belongs to one Prodgator organization, and its secret is generated by Prodgator when you connect.
Handled events
| Provider | Events |
|---|---|
| GitHub | , , , , , , , , , |
| GitLab | , , |
| Bitbucket | , |
| Azure DevOps | , , , , , , , , |
| Jenkins | Build results (one event type) |
Responses
| Status | Body | Meaning |
|---|---|---|
| Stored and queued for processing | ||
| Already received this delivery | ||
| An event type Prodgator does not use. Dropped | ||
| No provider could be detected | ||
| The body could not be parsed | ||
| The URL names a different provider than the headers | ||
| Verification failed | ||
| Unknown or disconnected connection ID | ||
| Could not store or queue the delivery. The provider's retry is safe |
Processing
Prodgator answers as soon as a delivery is stored, then processes it from a queue:
- Verify the delivery and store it for 15 days.
- Queue it for processing.
- Parse it with the provider's adapter into runs, jobs, deployments or alerts.
- Check the plan's monthly run and pipeline limits. A new run over the limit is not recorded; updates to runs already recorded are.
- Save the records, create notifications, and push the change to open browsers.
Retries and duplicates
A redelivery of the same event is recognized by the provider's delivery ID and not processed twice. Runs and jobs are keyed by the provider's own IDs, so a repeated or out-of-order event updates the existing record instead of creating a new one.