Trigger an Assignment from a Webhook

Webhooks let other systems start agent work the moment something happens — a new ticket, a form submission, a deploy. Any system that can send an HTTP POST can trigger an assignment.

Create an API key. In Settings → Workspace → API Keys, choose Create Key and name it after the caller (for example, ticketing-webhook). The full key — it starts with wak_ — is shown exactly once; store it in the calling system’s secret store. Afterward the UI shows only the key’s prefix, and you can rotate or revoke it anytime.
Enable the webhook trigger. On the assignment’s Schedule section, check Run via webhook and choose a path (for example, ticketing/new-ticket). The full URL appears with a copy button:
```
https://workprentice.ai/api/v1/hooks/<workspace-id>/ticketing/new-ticket
```
Attach your API key in the API Key dropdown. A webhook without a key accepts unauthenticated calls — attach one unless you have a specific reason not to.
Test with a dry run. Send a POST with the X-API-Key header and add ?run_type=dry_run — the agent does the work but is blocked from writing to external systems, so you can rehearse safely:
Terminal window
```
curl -X POST \
  "https://workprentice.ai/api/v1/hooks/<workspace-id>/ticketing/new-ticket?run_type=dry_run" \
  -H "X-API-Key: wak_..." \
  -H "Content-Type: application/json" \
  -d '{"ticket_id": "12345", "subject": "Cannot log in"}'
```
A successful trigger returns the session that started:
```
{ "session_id": "…", "run_type": "dry_run" }
```
Open that session in Workprentice to watch the run. The JSON body you POST is handed to the agent as the webhook payload, so the assignment’s instructions can refer to it (“enrich the ticket in the payload…”).
Go live. Point the real system at the URL without the dry-run parameter. Every delivery starts a session; paused assignments return 403, unknown paths 404, and bad keys 401, so callers get clean signals.

Instructions for a webhook-triggered assignment read like any other, except they can lean on the payload. For the ticketing example:

A new support ticket arrives as the webhook payload, with a ticket id and subject. Look up the ticket in Zendesk and classify its severity. Draft a suggested first response, and add a row to the Ticket Triage data table with the ticket id, severity, and your draft. If the ticket describes an outage, escalate to my Inbox as Urgent instead of waiting for the next review.

Variations

Anything that can send an HTTP POST works as a caller, which makes this the pattern for reacting to events rather than the clock:

Form submission to enriched lead. Have your form tool POST each new signup. The agent enriches the lead with ZoomInfo or Clay, then writes the result into HubSpot or Salesforce — enrichment done before anyone opens the CRM.
Post-deploy check. A key named ci-pipeline and a POST at the end of each deploy: the agent checks Sentry for new errors against the release and escalates to your Inbox only when something regressed, so a quiet deploy stays quiet.
Triage queue. Each delivery appends a row to a data table with a status column a human advances — the webhook fills the queue, and the table is the queue.

The dry-run parameter is useful beyond initial setup: whenever you revise the instructions, rehearse the change with ?run_type=dry_run before real deliveries hit it. The full contract — key management, headers, and error codes — lives in API keys and webhooks.