---
title: Support
description: Where to get help, and what to include so it can be answered quickly.
---

import { SUPPORT_EMAIL, PANEL_URL, EXPLORER_URL, REPO_URL, PROTO_URL } from "/snippets/vars.mdx";

| Need | Where |
| --- | --- |
| Integration help, key issues, stuck orders | {SUPPORT_EMAIL} |
| API keys and referral claims | {PANEL_URL} |
| Order status | {EXPLORER_URL} |
| Protobuf definition | {PROTO_URL} |
| Source | {REPO_URL} |

## Reporting a stuck order

Include the quote hash. It resolves everything else: the quote, the deposit, the order state, and any fulfillment or refund attempts.

If you only have a transaction hash, `Search` accepts source and destination transaction hashes as well and returns the same detail. See [Track an order](/integration/track).

Useful to include:

- The quote hash, or a transaction hash.
- The order state you last observed.
- What you expected to happen.

## Before writing in

A few states look like failures and are not:

| Observation | Likely explanation |
| --- | --- |
| `GetOrder` returns a quote with no order | The deposit has not been indexed yet. Normal for the first seconds. |
| Order sitting in `pending_refund` | The refund is waiting for gas to come down. It submits on its own. |
| Order in `awaiting_refund_window` | A transaction outcome is being resolved against the chain. It moves on its own. |
| `insufficient inventory` on a quote | Size-dependent and temporary. A smaller amount usually quotes immediately. |

The states that genuinely need a human are `refund_skipped`, `unsupported_deposit`, `refund_failed`, and `deposit_missing`. See [Order lifecycle](/concepts/order-lifecycle).