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

# Status sync

Use webhooks first. Call `monitor-status` when the user refreshes or a callback is delayed.

> **When to use this**
> This is your recovery path, not your primary state source. Use it when you need to confirm what happened after the webhook path slowed down.

## Request

```bash theme={null}
curl -X POST "https://api.ramphub.io/api/developer/orders/0d4b7fb0-66f7-4a52-9183-7c3fe44f0db2/monitor-status" \
  -H "x-api-key: rh_test_..."
```

## Response

The recovery response includes the latest RampHub truth for the transaction. The most useful fields are:

* `success`
* `transactionId`
* `status`
* `terminal`
* `completed`
* `synchronizedAt`
* `trackable`
* `syncQueued`
* `sandbox` for test-key flows
* `paychain` when PayChain has extra settlement context

```json theme={null}
{
  "success": true,
  "transactionId": "RH-TX-AB12CD34",
  "status": "pending",
  "terminal": false,
  "completed": false,
  "synchronizedAt": "2026-04-20T12:00:00.000Z",
  "trackable": true,
  "environment": "test",
  "sandbox": true,
  "syncQueued": true,
  "paychain": null
}
```

## Recovery rules

1. Listen for RampHub webhook events first.
2. Update local order state from webhook payloads.
3. Call `monitor-status` only when the user refreshes or a callback is delayed.
4. Mark an order terminal only when RampHub reports `completed` or `failed`.
5. Do not guess provider instructions or settlement state.
6. If a webhook stops verifying after a secret rotation, update the receiver secret first, then use status sync to recover the current truth.