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

# Requery

> Force Orchestrate to re-check a payment with the underlying provider and reconcile the stored status.

A requery instructs Orchestrate to fetch the current state of a payment directly from the provider and update the stored intent and attempt statuses accordingly.

## When to use

Requery is a **fallback mechanism**, not a polling strategy. Use it when:

* A payment has not settled and you suspect a provider delay or a missed webhook.
* A customer reports they completed a payment that Orchestrate still shows as pending.
* A service disruption may have prevented a webhook from being delivered.

Webhooks remain the primary signal. Build your integration around them and reach for requery only when the normal flow has broken down.

## Trigger a requery

```
POST /payment/intents/{intentId}/requery
```

No request body is required.

```bash theme={null}
curl -X POST https://api.orqex.com/v1/payment/intents/pi_.../requery \
  -H "Authorization: Bearer sk_live_..."
```

The response returns a requery resource describing what changed.

## Requery resource

<ResponseField name="id" type="string">
  Requery identifier. Always prefixed with `rq_`.
</ResponseField>

<ResponseField name="status" type="string">
  Status of the requery operation itself.
</ResponseField>

<ResponseField name="payment_intent_id" type="string">
  The intent that was requeried.
</ResponseField>

<ResponseField name="payment_attempt_id" type="string">
  The attempt that was checked against the provider.
</ResponseField>

<ResponseField name="before" type="object">
  Snapshot of statuses before the requery ran.

  | Field            | Description                       |
  | ---------------- | --------------------------------- |
  | `intent_status`  | Intent status before the requery  |
  | `attempt_status` | Attempt status before the requery |
</ResponseField>

<ResponseField name="after" type="object">
  Snapshot of statuses after the requery ran.

  | Field            | Description                      |
  | ---------------- | -------------------------------- |
  | `intent_status`  | Intent status after the requery  |
  | `attempt_status` | Attempt status after the requery |
</ResponseField>

<ResponseField name="attempts" type="object">
  | Field       | Description                                    |
  | ----------- | ---------------------------------------------- |
  | `count`     | Total number of attempts on the intent         |
  | `requeried` | Number of attempts checked during this requery |
</ResponseField>

<ResponseField name="completed_at" type="string | null">
  ISO 8601 timestamp when the requery completed.
</ResponseField>

<ResponseField name="created_at" type="string">
  ISO 8601 timestamp when the requery was created.
</ResponseField>

## Example response

```json theme={null}
{
  "message": "Requery completed.",
  "data": {
    "id": "rq_...",
    "status": "completed",
    "payment_intent_id": "pi_...",
    "payment_attempt_id": "pa_...",
    "before": {
      "intent_status": "pending",
      "attempt_status": "processing"
    },
    "after": {
      "intent_status": "completed",
      "attempt_status": "completed"
    },
    "attempts": {
      "count": 1,
      "requeried": 1
    },
    "completed_at": "2025-01-01T00:01:30Z",
    "created_at": "2025-01-01T00:01:00Z"
  }
}
```

Compare `before` and `after` to understand whether the requery changed anything. If the statuses are the same, the provider's record also shows no change.