Skip to main content
A callback resumes a run already parked on wait_for_callback. It is not a generic Workflow trigger and it cannot start a new run.

​
Author the wait

When the run reaches this call, Noorle records a callback wait and exposes a callback_path in run status and the Portal run detail:
The full production URL uses the hooks host:
The caller or integration coordinating the run reads that path and gives it to the external system that will complete the work.

​
Deliver the callback

The JSON body becomes the result of wait_for_callback, and the same version-pinned Program resumes. The error is deliberately opaque so the endpoint does not reveal whether a run or wait exists.

​
Security model

The token is a signed bearer credential minted for one recorded wait. It is bound to the account, run, and exact wait identity; it is not an API key and is not reusable for a later callback in the same Program.
  • Treat the full URL as a secret.
  • Send it only over HTTPS.
  • Do not log it in application telemetry or place it in Program source.
  • Expect a late or repeated delivery to be rejected.
The callback route uses the bearer token instead of Noorle API authentication. Outbound calls that create third-party work should still use a connector for their own credentials.

​
Current limits

  • Callback waits have no built-in timeout. They remain parked until a callback arrives or the run is canceled.
  • The callback path exists only after the run has parked. It is not available inside Program source before wait_for_callback is reached.
  • There is no per-Workflow webhook that starts a run. Start through the Portal, an Agent or gateway attachment, an Automation, a parent Workflow, or the Management API.

​
Callback or signal?

​
Next