Sandbox

Run the integration against your own wallet

The same five calls your users will make, answered by the same code — with nothing sent to Hyperliquid and nothing kept on our side.

What this page will and will not do. It asks your wallet for your address, then walks the whole enrollment. The two typed-data messages are built by the production code, so your wallet shows exactly what your users will see. If you sign them, we verify the signature and tell you which address it came from — then discard it.

No order is placed, no agent is approved on your account, no key is ever handed to anyone, and the agent address in these messages belongs to a keypair thrown away the moment it was made. Every response carries "sandbox": true.

The walkthrough

Connect a wallet to begin. Any EIP-1193 wallet works — MetaMask, Rabby, Phantom.

  1. Open a session

    POST /api/v1/partner/sandbox/session — in production this is also what attributes the user to you.

  2. Ask for the agent approval

    …/enroll/agent-request — returns the EIP-712 message. An agent can trade; it can never withdraw.

  3. Sign it, and we check who signed

    …/enroll/agent-submit — this is where a wallet connector usually breaks, so the answer is explicit.

  4. The fee approval

    …/enroll/fee-request then fee-submit — a capped rate, charged only when a position is actually rescued.

  5. Read the state back

    GET …/sandbox/status?address= — what your interface polls to show “Protected”. The sandbox walks the same three states as production — not_enrolled, agent_approved, protected — so you can wire your UI against real transitions. Call it before step 2 and it will say not_enrolled.

When it works

Remove /sandbox from the five paths and put your partner code in the session call. Nothing else changes. Ask us for the code — we answer in writing, and the revenue share is 30% of what we collect on your users.

The integration page, with the copy–paste version