# API reference

Build against the contract your environment actually serves.

## Choose your API

| | Partner API | Sandbox API |
| --- | --- | --- |
| Use it for | Partner attribution, reporting and operations | Prototyping an Earn customer journey |
| Connection | URL and credential assigned during onboarding | Developer console sandbox |
| Assets | USDC, USDT0 | USDC, USDT |
| SDK | `PartnerClient` | `SandboxClient` |
| Reference | [43 methods](/api/partner/) | [36 methods](/api/sandbox/) |

The two APIs share conventions but do not have interchangeable paths or response models. The sandbox's simulated `/positions` workflow is not a transaction endpoint on the Partner API.

## Shared conventions

Send JSON request bodies with `Content-Type: application/json`. Authentication uses a Bearer key. Responses wrap the resource in `data`; list responses may include pagination metadata. Both SDKs return `data` and retain response metadata separately.

Start with [authentication](/build/authentication/), [units](/build/units/) and [errors](/build/errors/). Then use the method reference for the exact required scope, query parameters and response fields.

## Machine-readable contracts

[Partner OpenAPI](/openapi/partner-openapi.json) · [Sandbox OpenAPI](/openapi/sandbox-openapi.json)

The Partner schema is exported from the current backend and checked against responses from all 43 methods in a local test database. The sandbox schema describes the separate developer-portal implementation.