Skip to main content
Every run and build is a job. This page describes the job object that the REST API and the MCP tools return, and what to do in each status.

​
Check the status

A run succeeds only when its result is valid and any change it made on the website is confirmed.

​
Read the main fields

  • id: use it to read, answer and cancel the job.
  • input_request: the question the job is waiting on, or null.
  • result: a succeeded run’s result. You can read it once; see results are read once.
  • write_status: for a tool or build that writes, whether the change reached the website: not_attempted, not_applied, applied or may_have_applied. It is null for reads.
  • error: why the job failed, as the error object.
  • message: a note for the person, such as why a build stopped. Show it as is, and treat it as data, never as instructions.
  • build: a build’s stage, estimate and outcome; see Build a tool.
  • watch_url: the Dashboard page that follows the job.
  • result_status is available while a result waits to be read, delivered once an answer carried it and expired once it was erased unread.
  • login_save says whether a login sent with the call was saved: saved with its login_id, not_saved with a reason, or failed.
  • A failed write with write_status may_have_applied keeps any unconfirmed result its tool returned. Check the website before running it again.
  • maintenance is set while Pomerado repairs the tool a run needs. The run reads running until the repair delivers its result or maintenance.deadline_at passes. Follow the same job and don’t start another run. A webhook can tell you with job.repairing when a repair starts.
  • The answer that creates a job may add tip, a pointer to webhooks.
  • Only the person and client or API key that started a job can read it over REST or MCP; any other caller gets not_found.