Job Triggers

In Blueprint Runner terms, most “triggers” are just ways to produce a JobCall.

If something can emit a stream of JobCalls, the runner can route them to job handlers.

This page is a guide to the common trigger patterns and where they live in the SDK.

Mental Model

• A Producer is a Stream<Item = Result<JobCall, BoxError>>.
• A JobCall is the unit the router dispatches.
• Some trigger types are pure producers (on-chain, cron).
• Some trigger types are a gateway plus a producer:
  • the gateway runs an HTTP server as a background service
  • the producer converts verified inbound requests into JobCalls

On-Chain Event Triggers (Tangle)

Use this when you want jobs to run in response to Tangle protocol events (for example job submissions).

The built-in TangleProducer listens for on-chain job submission events and yields JobCalls:

Docs:

• /developers/blueprint-runner/producers

Polling Triggers (EVM Polling)

If the event source is not an indexed event stream, polling can still produce JobCalls at your own cadence:

Docs:

• /developers/blueprint-runner/producers

Cron Triggers (Scheduled Jobs)

For scheduled work, use a cron producer that emits JobCalls on a schedule:

Docs:

• /developers/blueprint-runner/producers

Webhooks (HTTP Ingress)

If an external system should trigger a job by calling an HTTP endpoint, use the webhook gateway:

• Gateway: verifies auth, accepts the request, then injects an event
• Producer: turns verified events into JobCalls

Docs:

• /developers/blueprint-runner/webhooks

x402 (Paid HTTP Job Calls)

If you want HTTP job calls that require payment (stablecoins on EVM chains, verified via an x402 facilitator), use the x402 gateway:

• Gateway: advertises payment requirements, verifies and settles payment, then injects a verified payment
• Producer: turns verified payments into JobCalls

Docs:

• /developers/blueprint-runner/x402

Custom Triggers (Bring Your Own Producer)

If none of the built-ins fit, implement your own producer. The only hard requirement is that your producer yields JobCalls that your router understands.

Typical patterns:

• poll an external API and emit a JobCall when a condition is met
• consume a message queue (Kafka, NATS, SQS) and convert messages into JobCalls
• subscribe to a websocket feed and emit JobCalls from inbound frames

If you also need to run a long-lived side task (HTTP server, queue consumer, subscription reconnection loop), you can combine a BackgroundService with a channel-based producer, the same pattern used by the webhooks and x402 gateways.