Pipeline Triggers

Pipelines support two trigger types that control how the pipeline is started and what data flows into it. The trigger is configured as the first node in the visual pipeline editor.

Trigger types

Type	Description
Manual / API	Call the pipeline URL directly with an API key (or without, if public)
Webhook	External services push a payload that becomes pipeline input

Both trigger types use the same URL:

POST https://api.wrapd.sh/v1/:username/:pipeline-slug

In local dev, substitute your API base URL (e.g. http://192.168.1.114:7502).

Configuring the trigger

1. Open the pipeline in the visual editor
2. Click the trigger node (the first node with no incoming edges)
3. Choose the trigger type: Manual/API or Webhook
4. Optionally toggle Public access to skip the API key requirement
5. For webhook triggers: define an input schema with field names and types

Manual / API trigger

The default trigger type. Call the pipeline URL with an X-API-Key header to start a run.

curl -X POST https://api.wrapd.sh/v1/yourname/deploy-pipeline \
  -H "X-API-Key: your-api-key"

The pipeline starts immediately and runs through all steps in the defined DAG order.

Public pipelines

Toggle Public access on the trigger node to allow calls without an API key:

curl -X POST https://api.wrapd.sh/v1/yourname/deploy-pipeline

Caution

Public pipelines are callable by anyone who knows the URL. Only use this for pipelines that are safe to run without authentication.

Webhook trigger

Webhook triggers accept a JSON request body and make its fields available to downstream steps. This is useful for pipelines that react to external events (GitHub pushes, Stripe payments, monitoring alerts).

Defining the input schema

When you select Webhook as the trigger type, an input schema editor appears. Define the fields your pipeline expects:

Field name	Type	Example value
repo	string	"wrapd"
branch	string	"main"
commit_count	number	3
force	boolean	true
metadata	object	{"author": "jose"}

Available types: string, number, boolean, object.

Referencing input in steps

Downstream steps access webhook payload fields using the {input.field_name} syntax in their parameters:

• {input.repo} — resolves to the repo value from the webhook payload
• {input.branch} — resolves to the branch value
• {input.metadata} — resolves to the full JSON object

Use these references in step environment variables, command arguments, or anywhere step params accept text.

Example: webhook-triggered deploy pipeline

A pipeline with slug deploy-on-push that deploys a specific branch when triggered by a webhook:

1. Trigger node — type: Webhook, input schema: repo (string), branch (string)
2. Step 1 — endpoint: pull-repo, env: REPO={input.repo}, BRANCH={input.branch}
3. Step 2 — endpoint: run-tests, on failure: stop
4. Step 3 — endpoint: deploy, env: BRANCH={input.branch}

Call it with:

curl -X POST https://api.wrapd.sh/v1/yourname/deploy-on-push \
  -H "X-API-Key: your-api-key" \
  -H "Content-Type: application/json" \
  -d '{"repo": "wrapd", "branch": "main"}'

Or for a public webhook pipeline (e.g. called by GitHub):

curl -X POST https://api.wrapd.sh/v1/yourname/deploy-on-push \
  -H "Content-Type: application/json" \
  -d '{"repo": "wrapd", "branch": "main"}'

Inside step 1, the environment variables REPO and BRANCH resolve to wrapd and main respectively.

Combining with condition nodes

Webhook input fields can be used in condition node expressions too. For example, to only deploy when the branch is main:

{input.branch} == main

This lets you build pipelines that filter or branch based on the incoming webhook data.