Webhook Overview

Fastfold supports webhook-driven automation for both:

• fold job lifecycle events (source_kind: fold_job)
• workflow lifecycle events (source_kind: workflow)

Use webhooks when you want downstream actions like:

• auto-create Evolla chat runs after fold completion
• auto-create OpenMM runs after fold completion
• post event payloads to your own HTTPS endpoint

For SDK and CLI recipes that enable these webhook flows in real submit payloads, see SDK Webhooks.

Authentication

All webhook configuration endpoints use normal API auth:

Authorization: Bearer <FASTFOLD_API_KEY>

For custom destination delivery, Fastfold sends your configured token in:

X-Webhook-Token: <your_secret_token>

Event model

Webhook events are normalized around:

• source_kind: fold_job or workflow
• event_name: on_complete or on_failed
• status: terminal state (COMPLETED / FAILED etc.)

Delivery modes

You can use webhook automation in two ways:

1. Per-run enablement
   Set webhook fields in job/workflow inputs (for example constraints.webhooks.* on fold jobs, or workflow_input.webhooks.* on workflows).

2. Global custom webhook default
   Configure /v1/webhooks/custom-http-config and set enabled_by_default: true so new runs inherit custom webhook delivery without explicitly passing webhook fields each time.

Internal event ingest (for platform operators)

Fastfold internally bridges runtime events to:

• POST /v1/webhooks/events/ingest

This endpoint requires:

X-Webhook-Ingest-Secret: <internal_shared_secret>

It is not meant for normal external API clients.