> For the complete documentation index, see [llms.txt](https://developers.unigox.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developers.unigox.com/basics/how-it-works.md).

# How it works

This section explains the runtime behavior around the API, especially the parts you rely on operationally: webhooks, order progression, and production readiness.

## How the Unigox flow works

For off-ramp, the integration has four broad stages:

1. One-time setup
2. Your user onboarding
3. Per-order execution
4. Monitoring and reconciliation

The API reference pages provide payload definitions. This page explains how those pieces behave together.

## Order Lifecycle

The normal off-ramp lifecycle is:

1. Quote
2. Initiate offramp
3. Authorize your crypto transfer
4. Wait for payment proof and review from counterparty
5. You confirm that fiat was received
6. Completed

Important status checkpoints:

* `awaiting_crypto_transfer_authorization`
* `crypto_received`
* `fiat_payment_started`
* `fiat_payment_review_started`
* `awaiting_fiat_received_confirmation`
* `completed`

Alternative terminal paths can include:

* `cancelled`
* `failed`
* `dispute_started`

For the actual order actions and state fields, see [Orders](broken://pages/EL7TgfuQ3LD07Z2gtOph).

## Moving to production

Before switching to production:

1. Verify webhook signatures end-to-end.
2. Confirm retries and idempotency behave correctly.
3. Run the happy path and at least one failure or cancellation path.
4. Make sure your reconciliation logic can fall back to polling when needed.