Webhooks 2.0

Buddy pipelines can now be triggered through configurable webhooks, offering a more secure, flexible, and controlled approach compared to what it was previously.

In the past, every pipeline was automatically assigned a webhook that could not be disabled, and authorization relied on a single permanent token that could not be rotated.

With the new mechanism, users can choose which pipelines have webhooks enabled, configure them either from the UI or via YAML/API, and regenerate tokens at any time, immediately invalidating the old ones. Additionally, webhook URLs can now be secured with Time-based One-Time Passwords (TOTP), further enhancing protection.

Enabling Webhooks

UI

You can add a webhook trigger from the Workflow tab of the pipeline.

Image loading...Adding a webhook trigger via UI

A webhook is automatically created and associated with the pipeline. To view the webhook URL and token, simply click the webhook trigger. This will open the webhook options panel, where you can access and manage all related settings.

Image loading...Webhook settings

YAML/API

In YAML or API definition the webhook must be explicitly defined. For example:

yaml
- pipeline: live-mirror name: Live mirror refs: - refs/heads/master events: - type: WEBHOOK totp: true - type: SCHEDULE start_date: 2025-10-01T05:09:00Z delay: 5 - type: PUSH

Security improvements

Each webhook is secured with its own unique token, ensuring that access is isolated and controlled. Tokens can be easily regenerated through the UI whenever needed, and once regenerated, the previous token is immediately invalidated to maintain security and prevent unauthorized use.

TOTP Authentication

For additional, optional protection, webhooks support multi-factor authentication using TOTP codes. When TOTP is enabled, a Base32-encoded secret key is generated, which can be used to produce one-time codes. These codes can be generated with widely available tools and libraries in Bash, JavaScript, and Python.

Python example:

python
import pyotp secret_base32 = "XXTSGKN6W42HRBDPUJQ32DNB43MXEQ3T" totp = pyotp.TOTP(secret_base32) print(totp.now()) # outputs a 6-digit code

API parameter customization

Webhook requests can pass parameters via the query string (GET) or the request body (POST).

Supported parameters:

  • branch – set branch to run (example: master)
  • clear_cache – clear caches before run (boolean)
  • comment – custom run comment
  • environment – specify environment
  • from_scratch – ignore last commit (boolean)
  • priority – run priority (HIGH, NORMAL, LOW)
  • pull_request – specify PR (e.g., pr/12)
  • revision – commit hash
  • tag – tag name
  • vars.* – pipeline variables

Example POST request:

http
POST https://app.awsdev.net/ttests/git-repo/pipelines/pipeline/30023/webhook?token=bud_wh_us_xxxx&code=942071 Content-Type: application/json { "revision": "b9e511d1287e2e11015ef4191f4917c14c79301c", "environment": "my-env", "from_scratch": "true", "clear_cache": "true", "comment": "My first webhook run", "priority": "HIGH", "vars": { "my_variable": "my_value" } }

Backwards compatibility

To ensure backwards compatibility, all workspaces have legacy webhooks enabled by default. Users can make a switch to the new webhook mechanism while continuing to use the old one in at the same time. Once pipelines have been fully migrated, workspace administrators can disable legacy webhooks at any time through Workspace Settings → Workspace tab.

Image loading...Legacy webhook setting

Jarek Dylewski

Jarek Dylewski

Customer Support

A journalist and an SEO specialist trying to find himself in the unforgiving world of coders. Gamer, a non-fiction literature fan and obsessive carnivore. Jarek uses his talents to convert the programming lingo into a cohesive and approachable narration.

Oct 1, 2025
Share