Auxot
Tutorials Docs Pricing Login

Poll an intake job until it finishes

Treat **`202 Accepted`** as a queue ticket: capture **`work_id`**, loop **`GET /v1/intake/{INTAKE_ID}/work/{WORK_ID}`** until **`completed`** or **`failed`**, from a shell script or CI job, without pretending the first POST already ran the workflow.

Plus: three Admin Agent prompts: paste stuck poll JSON, compare poll vs callback for your load profile, and sanity-check a GitHub Actions step block before you wire secrets.

Audience Admins · Developers
Time ~8 min
Prerequisites An intake already exists and points at a workflow ([Trigger a workflow with an intake webhook](/tutorials/trigger-a-workflow-with-an-intake-webhook)). A Bearer-capable API key ([Generate your first API key](/tutorials/generate-your-first-api-key); team automation → [Create a shared Team API Key](/tutorials/create-a-team-api-key)). **`curl`** and **`jq`** installed locally for the copy-paste blocks (CI can install them the same way).
You'll end up with A repeatable poll loop you trust: capture **`work_id`**, backoff while **`pending`** / **`running`**, stop on terminal status, and log enough JSON to debug when **`failed`** drops.

When a tutorial shows italic text in quotation marks, it usually mirrors a label or helper string inside Auxot. Product copy changes between releases — if something reads differently in your workspace, trust what you see on screen.

Callouts with a Worth knowing gold accent are meant as must-read context before you move on. Blockquotes that open with Tip are lighter, optional depth.

Why this matters

Intakes answer 202 fast on purpose: Auxot queued work; it did not promise the workflow finished. Callers that stop after curl -X POST learn the hard way in production when dashboards stay empty while 202 looked “fine.”

work_id is your correlation handle. GET /v1/intake/{INTAKE_ID}/work/{WORK_ID} (same host, same Bearer token Intake Webhooks) is how you learn whether the run is still moving or finally completed / failed.

This lesson is the happy-path poll story only: one outside trigger, one loop, one terminal outcome. Creating the intake, tightening workflow steps, and hardening secrets live in sibling tutorials below.

The next time you wire a webhook or CI job, you already know where the finish line is recorded: not in the POST status code, in the poll JSON.

202 hands you a lineup number; the GET tells you when the order is actually up.

Quick start

  1. Export three placeholders: BASE_URL (same origin you use in the browser, https://…), INTAKE_ID, and API_KEY (user.… or team.…).
  2. POST once: POST /v1/intake/{INTAKE_ID} with Authorization: Bearer …, JSON body your workflow expects; confirm HTTP 202 and a JSON body containing work_id.
  3. Capture WORK_ID: copy from the response (or pipe through jq -r .work_id).
  4. Poll: GET /v1/intake/{INTAKE_ID}/work/{WORK_ID} with the same Bearer token.
  5. Loop until terminal: repeat step 4 until the work item’s status reads completed or failed (anything else still counts as in-flight).

Done? You can paste one completed or failed JSON blob and explain how long the wait was.

The agent can do that?

You have the moving parts (intake, key, workflow). These prompts help interpret stuck polls and choose callback vs poll before traffic scales.

1. Decode a stuck poll

Paste: latest GET poll JSON for my intake work item (status still running). Workflow has human approval steps. Name the first three places I check in Auxot UI vs payload fields. No autonomous retries.

Why it’s non-obvious: running can mean GPUs, humans, or a bad step input. A short explanation beats staring at JSON alone.

2. Poll vs callback for your caller

Callers: [GitHub Actions / cron / internal queue]. Peak rate [N/min]. Compare sleeping on GET loops vs configuring Auxot intake callback URL. Ops tradeoffs only, no sermons.

Why it’s non-obvious: Poll is simple until concurrency spikes; callbacks move complexity to your HTTPS receiver (Trigger a workflow with an intake webhook).

3. CI shape review

Review this GitHub Actions YAML snippet (paste). Flag secret leakage risks, missing jq/error handling on POST, and whether we're polling with backoff. Assume Ubuntu runners.

Why it’s non-obvious: Logs leak Bearer when set -x meets curl. Paste it before you green-light the merge.

Go deeper

Terminal statuses

Treat pending and running as non-terminal. Stop looping on completed or failed. Log the full JSON on failure so workflow authors can see inputs vs step errors (Run a workflow).

Backoff

Sleep between polls (a few seconds is plenty for tutorials; production uses jitter and caps). Hammering sub-second GETs wastes rate limits and annoys operators.

Example bash loop (replace placeholders) 
#!/usr/bin/env bash
set -euo pipefail

BASE_URL="https://YOUR_HOST"
INTAKE_ID="YOUR_INTAKE_ID"
API_KEY="YOUR_USER_OR_TEAM_KEY"

BODY=$(curl -sS -X POST "${BASE_URL}/v1/intake/${INTAKE_ID}" \
  -H "Authorization: Bearer ${API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{"source":"poll-tutorial-smoke","note":"replace-with-real-shape"}')

WORK_ID=$(echo "$BODY" | jq -r '.work_id')

while true; do
  POLL=$(curl -sS "${BASE_URL}/v1/intake/${INTAKE_ID}/work/${WORK_ID}" \
    -H "Authorization: Bearer ${API_KEY}")
  STATUS=$(echo "$POLL" | jq -r '.status')
  echo "$(date -Iseconds) ${STATUS}"
  case "$STATUS" in
    completed|failed) echo "$POLL" | jq .; exit 0 ;;
    *) sleep 3 ;;
  esac
done

Swap the JSON body for whatever your workflow validates.

Walkthrough

Step 1: Confirm POST shape

Use the same JSON schema your workflow already accepts from Trigger a workflow with an intake webhook. If POST returns 401, fix Bearer spelling before you debug polls.

Step 2: Record work_id

Parse work_id immediately after 202. If your shell lacks jq, copy the id manually from the JSON. Without work_id, there is nothing to poll.

Step 3: Poll manually once

Run a single GET and read status. If you already see completed or failed, the workflow finished between POST and your first poll (short workflows do that).

Step 4: Automate the loop

Wrap GET in while / until with sleep, or translate the same loop into CI steps (Trigger a workflow from GitHub Actions carries GitHub-native patterns).

Step 5: Inspect failures

On failed, open View your audit logs and Trace a failing job end to end when you need row-level forensics beyond the poll payload.

What’s next

Reference

Browse all tutorials