> For the complete documentation index, see [llms.txt](https://docs.swapkit.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.swapkit.dev/guides/chain-specific-guides/integrate-near-on-an-existing-swapkit-integration.md).

# Integrate NEAR on an existing SwapKit integration

NEAR is a swap provider that routes cross-chain swaps through NEAR Intents. It follows the standard [quote and swap flow](/get-started/quote-and-swap-implementation-flow.md), so an existing SwapKit integration picks up NEAR routes with no code changes — they simply start appearing in `/v3/quote` responses for supported pairs.

Two things are worth knowing before you ship: how to recognise a NEAR route, and what its transaction looks like.

### Provider Identification

`/v3/quote` returns a `routes` array, and each route carries its own `providers`. A NEAR route shows `"NEAR"` there:

```json
{
  "routes": [
    {
      "routeId": "85bb4fa2-3a65-4d22-b20b-e43d028d83e6",
      "providers": ["NEAR"]
    }
  ]
}
```

NEAR is considered whenever `providers` is omitted from the request, which is the default. If you already restrict that array, add `"NEAR"` to it.

### Supported Chains

NEAR's coverage changes as chains are added, so read it from a live source rather than from this page: the **NEAR** entry on [SwapKit's trade offerings](/api-reference/swapkits-trade-offerings.md) is regenerated from the API, and [`GET /providers`](/api-reference/providers-providers-status-and-identifiers-mapping.md) reports what is enabled right now.

### Transaction shape

NEAR settles by **deposit**: the transaction [`/v3/swap`](/api-reference/v3-swap-obtain-swap-transaction-details.md) returns funds a deposit address created for your swap, rather than calling a settlement contract the way an on-chain DEX route does.

What that transaction looks like depends on the asset being sold, and you don't have to guess — each route's `txHint` says which shape it will be:

* `simpleTransfer` — a plain value transfer to the deposit address.
* `transferWithMemo` — the same, but the memo is load-bearing and must survive.
* `contractCall` — a token sell. An ERC-20 transfer on EVM, an `ft_transfer_call` on NEAR, so the transaction is addressed to **the token's own contract** rather than to the deposit address.

`txHint` comes back on the quote and is guaranteed to match what `/v3/swap` builds for the same `routeId`, so you can filter routes your wallet can't sign before you ever call `/v3/swap`.

The one thing to watch: don't gate signing on the transaction's target matching a deposit address, because on `contractCall` routes it legitimately won't.

### Confirmations and timing

A deposit has to confirm on its own chain before the swap starts, so how long that takes depends on which chain you're selling from. The quote already accounts for it — read `estimatedTime` off the response rather than hard-coding a figure.

### Example Integration

The standard two-step flow, with nothing NEAR-specific in it:

1. **Quote** — unchanged from any other swap:

```bash
curl -X POST "https://api.swapkit.dev/v3/quote" \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -d '{
    "sellAsset": "BTC.BTC",
    "buyAsset": "ETH.ETH",
    "sellAmount": "0.1"
  }'
```

2. **Route selection** — present the routes to the user and let them choose.
3. **Transaction building** — post the chosen route's `routeId` to `/v3/swap` with the addresses. The `routeId` is cached for 5 minutes.

```bash
curl -X POST "https://api.swapkit.dev/v3/swap" \
  -H "Content-Type: application/json" \
  -H "x-api-key: YOUR_API_KEY" \
  -d '{
    "routeId": "85bb4fa2-3a65-4d22-b20b-e43d028d83e6",
    "sourceAddress": "357a3So9CbsNfBBgFYACGvxxS6tMaDoa1P",
    "destinationAddress": "0x0a4c79cE84202b03e95B7a692E5D728d83C44c76"
  }'
```

4. **Sign and broadcast** the returned transaction with your existing wallet integration.