Status sync - RampHub

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

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

{
  "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

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

⌘I