Trigger reference

TWL Tool has two trigger surfaces:

• Workflow-definition triggers live in resources.workflowDefinitions.*.definition.triggers and launch that workflow.
• Durable trigger resources live in resources.triggers. They match stored events, evaluate conditions, and run one or more trigger actions.

Native trigger types

Type	Event	Source	Configuration
manual	trigger.manual.requested	trigger.manual	No required fields
schedule	trigger.schedule.due	trigger.definition	every_minutes, integer of at least 1
webhook	trigger.webhook.received	trigger.webhook	path, method, signing_secret, signature_header_name
workflow	trigger.workflow.requested	trigger.workflow	No required fields
browser	trigger.browser.received	trigger.browser	No required fields

Webhook methods are GET, POST, PUT, PATCH, and DELETE. The default is POST. When signing_secret is set, the request body must carry a valid HMAC signature in the configured header.

Workflow-definition syntax

Manual and webhook triggers can be declared inline:

definition: {
  version: 1,
  triggers: [
    {key: 'run-now', type: 'manual', launch: true},
    {
      key: 'incoming-record',
      type: 'webhook',
      operation: 'create-item',
      launch: true,
    },
  ],
  steps: [/* ... */],
}

Browser network responses have a typed builder:

import {listeners} from '@twl-tool/app-sdk';

listeners.networkResponse({
  key: 'capture-search',
  match: {
    urlPatterns: ['https://api.example.com/v1/search*'],
    methods: ['GET'],
    query: {type: {equals: 'people'}},
  },
  capture: {
    requestBody: false,
    requestHeaders: false,
    responseBody: true,
    responseHeaders: false,
    maxBodyBytes: 10_485_760,
  },
  redact: ['authorization', 'cookie', 'set-cookie'],
  launch: true,
  metadata: {source: 'people-search'},
});

match.urlPatterns is required. Optional browser fields are methods, query, capture, redact, installationId, launch, and metadata.

Durable trigger resource

Use a durable resource when you need explicit event matching, conditions, or several actions:

import {defineApp, ref} from '@twl-tool/app-sdk';

export default defineApp({
  key: 'lead-intake',
  name: 'Lead Intake',
  version: '1.0.0',
  resources: {
    workflowDefinitions: {
      qualifyLead: {/* ... */},
    },
    triggers: {
      incomingLead: {
        name: 'Incoming lead',
        slug: 'incoming-lead',
        eventType: 'trigger.webhook.received',
        sourceType: 'trigger.webhook',
        conditions: {
          mode: 'all',
          rules: [
            {path: 'payload.kind', operator: 'equals', value: 'lead.created'},
          ],
        },
        actions: [{
          type: 'workflow.run',
          workflow_definition_id: ref('workflowDefinitions', 'qualifyLead'),
          context: {
            lead: '{{ event.payload }}',
            triggerEventId: '{{ event.event_id }}',
          },
        }],
        meta: {
          trigger: {
            type: 'webhook',
            config: {
              path: 'incoming-lead',
              method: 'POST',
              signature_header_name: 'Signature',
            },
          },
        },
      },
    },
  },
});

Imported trigger resources are disabled by default until explicitly enabled. Configure signing_secret after installation through a trusted server-side setup path; the v1 app DSL does not provide a secret-value primitive, so a real signing secret must never be committed to the manifest.

Conditions

A condition set uses mode: 'all' or mode: 'any' and a rules list. Common operators include equality checks and change detection. Paths address the event payload, for example values.status, changed_columns, or payload.kind.

Trigger actions

Action type	Required fields	Result
workflow.run	workflow_definition_id; optional context	Creates a workflow run and injects trigger metadata and payload
log	Optional message	Writes a structured application log entry

Action context supports {{ event.path }} placeholders. A placeholder that occupies the entire string preserves arrays and objects; an embedded placeholder is converted to text.

Provider-specific events

An enabled integration may add event templates for objects such as messages, contacts, files, tickets, orders, or calendar events. Those names and payload schemas are provider-specific and come from the target server's live workflow-node and trigger-template catalogs:

GET /api/v1/apps-layer/platform-schema
GET /api/v1/triggers/templates

Provider events ultimately enter the same durable trigger engine, so they can use the same conditions and workflow.run actions. If a provider event is not exposed as a template, receive it through a signed webhook trigger instead.

Runtime endpoints

Purpose	Endpoint
Manual launch	POST /api/v1/triggers/manual/{slug}/trigger
Incoming webhook	GET|POST|PUT|PATCH|DELETE /api/v1/triggers/webhooks/{slug}
Workflow-to-workflow	POST /api/v1/triggers/workflows/{slug}/trigger
Browser event	POST /api/v1/triggers/browser/{slug}/trigger
List templates	GET /api/v1/triggers/templates
Create from template	POST /api/v1/triggers/templates/{templateKey}