Skip to main content
Every job has a trigger URL, shown at the top of its job page next to its API key. Calling it is ordinary HTTP: the key in the x-api-key header, JSON in the body, structured JSON back.

​
Synchronous by default

By default the call holds until the job finishes and returns the job’s output as the response body. The status code tells you how the run went: Synchronous calls fit jobs that finish in seconds to a couple of minutes. Desktop automations are slower than a database query; set your client timeout accordingly.

​
Asynchronous for long work

For long-running jobs, ask for an execution instead of holding the connection. Add ?async=1 to the URL (or send the x-job-async: true header) and the call returns 202 immediately:
Poll the result path on the same host with the same API key until the execution reports done, then read the output from the response. The poll is also how you follow a run in progress: the status moves from queued to running to a terminal state, with done: true and the output once it finishes. If you would rather be told than ask, status webhooks push events to your endpoint as the run progresses.

​
Inputs

Query parameters and the JSON body merge into a single input object for the job. What you send is what you taught: the samples you used in teaching are the contract for what a live call should look like. The full request and response contract, including reserved paths and the per-job OpenAPI document, is in the API reference.