> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fuseai.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Long-running work

> What a 202 means here, and which handle to poll for each kind of background job

Plenty of calls in this API start work rather than finish it. They answer **202 Accepted** with a handle, and the work lands over the following seconds or minutes.

There is no single poller. The handle you get back tells you which one to use, and they are not interchangeable — this page maps them.

## What 202 means

A `202` means the request was accepted and validated, not that the work succeeded. Two things follow from that:

* **Credits are usually spent by the background work, not the call.** A `202` is not a receipt.
* **Failure arrives later.** A job can accept cleanly and then fail per row, or find nothing at all.

Anything that answers `200` or `201` has already finished by the time you read it.

## Which handle to poll

| What you started                   | You get back     | Follow it with                                              |
| ---------------------------------- | ---------------- | ----------------------------------------------------------- |
| Export a list                      | `jobId`          | `GET /business/exports/{jobId}`                             |
| A CRM-side job (`jobId` is 24-hex) | `jobId`          | `GET /business/jobs/{jobId}`                                |
| Smart column create or re-run      | `jobId`          | `GET /business/lists/{listId}/smart-columns/{jobId}/status` |
| Import commit                      | `jobId` (a UUID) | the destination list's `completionStatus` — see below       |
| Save a search to a list            | `listIds`        | the list's `completionStatus`                               |
| Start an agent                     | the agent        | `GET /business/agents/{agentId}` and read `status`          |
| Start a research run               | `runId`          | `GET /business/research/runs/{runId}/events`                |
| Build a knowledge hub              | the hub          | `GET /business/knowledge-hubs/{hubId}` and read `status`    |

<Warning>
  `GET /business/jobs/{jobId}` serves CRM async jobs only — the 24-character hex ids. An import commit returns a **UUID**, which that endpoint cannot read. Follow an import through its destination list instead.
</Warning>

## Following a list that is filling

Saving a search to a list and committing an import both work the same way: the list exists immediately and fills in the background. Read the list and watch `completionStatus`.

```bash theme={null}
curl https://api.tryfuse.ai/api/v1/business/lists/$LIST_ID -u "$FUSE_API_KEY:"
```

Row counts climb while it runs, so a list that reports rows is not necessarily finished.

## Following a job

Job pollers report progress and, where the work bills, what it has spent so far:

```json theme={null}
{
  "job": {
    "status": "processing",
    "totalRows": 100,
    "processedRows": 40,
    "successfulRows": 38,
    "failedRows": 2,
    "creditsUsed": 76
  }
}
```

`failedRows` is worth reading on every poll. A job can complete with failures — those rows simply have no answer — and nothing else will tell you.

## Following a research run

Research runs report a stream of events rather than a percentage, because the interesting part is what the run is doing:

```bash theme={null}
curl -G https://api.tryfuse.ai/api/v1/business/research/runs/$RUN_ID/events \
  --data-urlencode "sinceSeq=0" \
  -u "$FUSE_API_KEY:"
```

Each event carries a `seq`. Pass the last one you saw as `sinceSeq` on the next call to get only what is new, and stop when the run's `status` is terminal.

## How often to poll

Every poll counts against your [rate limit](/concepts/rate-limits), and several families share one bucket. A few rules that keep you inside it:

<Steps>
  <Step title="Wait before the first poll">
    Nothing meaningful has happened one second after a 202.
  </Step>

  <Step title="Back off as it runs">
    A few seconds apart early, then widen. Long jobs rarely need per-second resolution.
  </Step>

  <Step title="Use the cursor where there is one">
    `sinceSeq` on research events returns only new events instead of the whole history.
  </Step>

  <Step title="Stop on a terminal status">
    Poll a finished job and you are spending rate limit on a fixed answer.
  </Step>
</Steps>

On `429`, wait for the window named in the response headers rather than retrying immediately.