Sc Scrupp

Task API

Async exports/enrichment return a process_id. Use Task API to check status and fetch results.

Async tasks api_key in query (legacy) Tasks
Core
Notes
  • api_key in query is legacy. Prefer Authorization: Bearer in new integrations.
  • Use /status for lightweight polling and /data to fetch the full payload.
  • If you send webhook_url in the original POST request, you can avoid polling.
Navigation
Check status Get data Polling strategy Errors Use cases
GET

Check Task Status

/task/{process_id}/status
Lightweight endpoint to see if a task is queued/running/completed before fetching full data.
Up Link
Request
Part Field Type Notes
Path process_id number Returned by async endpoints
Query api_key string Required (legacy)
Example
GET /task/6666/status?api_key=YOUR_API_KEY
Response examples
Queued
{
  "process_id": 6666,
  "status": "queued"
}
Running
{
  "process_id": 6666,
  "status": "running"
}
Completed
{
  "process_id": 6666,
  "status": "completed"
}
Failed
{
  "process_id": 6666,
  "status": "failed",
  "error": "Message (optional)"
}
Status strings are stable; additional keys may appear over time.
GET

Get Task Data

/task/{process_id}/data
Fetch the final result payload (items + total). Use after status becomes completed.
Up Link
Request
Part Field Type Notes
Path process_id number Returned by async endpoints
Query api_key string Required (legacy)
Example
GET /task/6666/data?api_key=YOUR_API_KEY
If you call /data too early, the task may return empty/partial output depending on job type. Prefer /status first.
Response (shape)
{
  "total": 100,
  "items": [
    { "...": "..." }
  ]
}
Example (short)
{
  "total": 2,
  "items": [
    {
      "company_name": "Google",
      "company_domain": "goo.gle",
      "company_linkedin": "https://www.linkedin.com/company/google"
    }
  ]
}
Fields depend on the originating endpoint and what data is available (email/phone/company fields/etc.).

Polling strategy

Recommended approach to avoid rate spikes and keep automations stable.

Best practice
Simple loop
  1. Call GET /task/{id}/status
  2. If queued or running → wait 3–10 seconds
  3. Repeat (max attempts)
  4. When completed → fetch /data
Webhook alternative
If the originating POST supports it, pass webhook_url. We will call your endpoint when the task completes.
Webhook payload (example)
{
  "process_id": 6666,
  "status": "completed",
  "result_url": "/task/6666/data"
}
Return 200 OK quickly and fetch result_url asynchronously.

Errors

Common issues and what to do.

Troubleshooting
Typical causes
  • 404: invalid process_id (or task expired/cleaned up)
  • 401/403: wrong/missing auth (api_key / Bearer)
  • 429: too frequent polling → increase delay / reduce attempts
  • failed status: upstream source problem (invalid URL, session expired, rate-limited)
Tip: store process_id + originating request payload to make debugging easier.

Use cases

How teams use Task API in automations (Make / Zapier / Clay).

Automation
Make
  1. POST async endpoint → save process_id
  2. Sleep 5s
  3. GET status → router: completed?
  4. GET data → map rows
Zapier
  1. Webhook (POST async) → store id
  2. Delay
  3. Webhooks (GET status/data)
  4. Looping → push rows
Clay
  1. HTTP enrichment step creates task
  2. Poll status (light)
  3. Fetch data and map fields to columns
Quick curl
# status
curl "https://api.scrupp.com/task/6666/status?api_key=YOUR_API_KEY"

# data
curl "https://api.scrupp.com/task/6666/data?api_key=YOUR_API_KEY"