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

# Endpoint Polling

> Handle long-running asynchronous jobs with automated interval polling, timeout limits, and continueWhen/stopWhen conditions.

Modern enterprise architectures frequently execute operations asynchronously. Calling an API endpoint often yields an immediate `202 Accepted` response with a job ID, requiring repeated polling until the background task finishes.

Quixa's built-in **Endpoint Polling Engine** automates this lifecycle without requiring manual loop nodes or script timers.

```mermaid theme={null}
stateDiagram-v2
    [*] --> SubmitJob: POST /jobs/score-calculation
    SubmitJob --> PollingLoop: 202 Accepted (Job ID)
    
    state PollingLoop {
        CheckStatus: GET /jobs/{id}
        CheckStatus --> Evaluate
        Evaluate --> SleepInterval: continueWhen (status == PENDING)
        SleepInterval --> CheckStatus
    }

    Evaluate --> Complete: stopWhen (status == COMPLETED)
    Complete --> NextStep: Continue to Downstream Nodes
    Evaluate --> FailTimeout: Max Duration Exceeded
```

***

## 1. Configuring Polling

In the node's **Polling Tab**, toggle **Enable Endpoint Polling** and configure timing limits:

### Timing Limits

* **Polling Interval**: Delay between recurring requests (e.g., every `2 seconds` or `1 minute`).
* **Max Duration**: Absolute timeout limit (e.g., `5 minutes` or `1 hour`). If the job does not complete within this window, the node aborts with a polling timeout error.

***

## 2. Condition Rules: `continueWhen` vs `stopWhen`

Quixa provides dual-table condition rules for fine-grained status evaluation:

### `continueWhen` Rules (Keep Polling)

Specifies intermediate states during which Quixa should wait for the interval and poll again:

* Target: `body.status`
* Operator: `EQUALS`
* Value: `"IN_PROGRESS"` or `"PENDING"`

### `stopWhen` Rules (Completion Signal)

Specifies target terminal states that signal successful completion, immediately resuming downstream flow execution:

* Target: `body.status`
* Operator: `EQUALS`
* Value: `"COMPLETED"` or `"SUCCESS"`

***

## 3. Enterprise Use Cases

* **Asynchronous Risk & Scoring Engines**: Submitting an application calculation request, polling every 2 seconds until status changes from `CALCULATING` to `READY`, and feeding the resulting score into downstream loan decisioning.
* **Bulk Export & Report Compilation**: Triggering a multi-tenant CSV data compilation job and polling until the download URL is populated in the response payload.
* **Asynchronous Batch Settlement**: Polling payment batch status until ledger confirmation receipts are generated.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.