Socket Docs

LLM prompt — copy and paste into your coding agent

Migrate my Bungee API integration to the Socket Swap V3 API.
Use https://docs.socket.tech/llms-full.txt for full context and follow https://docs.socket.tech/integrate/migration-guide.

This guide covers the key differences between the legacy Bungee API (/api/v1/bungee/quote) and the Socket Swap V3 API (/v3/swap/quote), and what you need to change in your integration.

Why migrate?

The Socket Swap V3 API (/v3/swap/quote) is the unified endpoint for Socket routes. It provides:

A cleaner, normalized route model for same-chain swaps and cross-chain bridges
Simpler execution flow — just get a quote, approve (if needed), and send txData.object
No submit step — transactions are submitted directly on-chain, not via a Bungee submit endpoint
Status tracking via /v3/swap/status using the quoteId

Endpoint changes

Feature	Bungee API	Socket Swap V3 API
Quote endpoint	`GET /api/v1/bungee/quote`	`GET /v3/swap/quote`
Status endpoint	`GET /api/v1/bungee/status`	`GET /v3/swap/status`
Submit endpoint	`POST /api/v1/bungee/submit`	Not needed — submit `txData.object` directly on-chain
Route param	N/A	`userOps=tx` (required)
Transaction identifier	`requestHash`	`quoteId`

Response shape changes

The Swap V3 API returns a flat routes array instead of autoRoute / depositRoute / manualRoute sub-objects. Before (Bungee API):

{
  "success": true,
  "result": {
    "autoRoute": {
      "quoteId": "0x...",
      "requestHash": "0x...",
      "txData": { ... },
      "approvalData": { ... }
    }
  }
}

After (Socket Swap V3 API):

{
  "originChainId": 1,
  "destinationChainId": 10,
  "routes": [
    {
      "userOp": "tx",
      "quoteId": "0x...",
      "expiresAt": 1760000000,
      "output": { ... },
      "approval": { ... },
      "txData": {
        "kind": "evm_tx",
        "object": { "chainId": 1, "to": "0x...", "data": "0x...", "value": "0" }
      },
      "statusCheck": {
        "endpoint": "https://backend.socket.tech/v3/swap/status?quoteId=0x...",
        "intervalSec": 5
      }
    }
  ]
}

Execution flow changes

Before (Bungee API — Auto Mode):

GET /api/v1/bungee/quote → get autoRoute
Approve approvalData.spenderAddress if needed
Sign autoRoute.signTypedData with PermitWitnessTransferFrom
POST /api/v1/bungee/submit with signature → get requestHash
Poll GET /api/v1/bungee/status?requestHash=...

After (Socket Swap V3 API):

GET /v3/swap/quote?userOps=tx → get routes[]
Approve route.approval.spenderAddress if route.approval is present
Submit route.txData.object as a transaction from userAddress
Poll GET /v3/swap/status?quoteId=...

The biggest simplification is that you no longer need to sign EIP-712 typed data or call a submit endpoint. The Swap V3 API returns a ready-to-send transaction.

Status endpoint changes

Before:

GET /api/v1/bungee/status?requestHash=<requestHash>

After:

GET /v3/swap/status?quoteId=<quoteId>

The v3 status endpoint looks up execution state by quoteId.

Status values

The Swap V3 status response has two string fields:

status — high-level lifecycle state for integrators (what you should usually branch on)
statusCode — finer-grained Bungee/Socket pipeline code (same names as the old numeric enum, but as strings)

`status` (high-level)

Bungee numeric code (`bungeeStatusCode`)	Socket Swap V3 `status`	Meaning
`0` PENDING	`PENDING`	Quote/route not started yet
`1` ASSIGNED / `2` EXTRACTED	`IN_PROGRESS`	Source side known; destination still pending
`3` FULFILLED / `4` SETTLED	`COMPLETED`	Funds delivered
`5` EXPIRED	`EXPIRED`	Quote/execution window expired
`6` CANCELLED	`FAILED`	Route failed/cancelled
`7` REFUNDED	`REFUNDED`	Funds refunded

Deposit flows may also return: REFUNDING, REFUND_FAILED, MANUAL_REVIEW_REQUIRED.

`statusCode` (fine-grained)

These are the complete statusCode values returned by /v3/swap/status:

`statusCode`	Meaning
`PENDING`	Request submitted / not yet picked up
`ASSIGNED`	Solver/transmitter assigned and working on it
`EXTRACTED`	Source funds taken / source tx confirmed; bridging or destination execution still in progress
`FULFILLED`	Destination delivery complete
`SETTLED`	Fully settled after fulfillment
`EXPIRED`	Not processed within the time window
`CANCELLED`	Cancelled by user or system
`REFUNDED`	Refund processed

EXTRACTED in plain terms: the source-chain extraction tx is confirmed (funds left the user / entered the bridge pipeline), but the destination fulfillment tx is not complete yet. Treat it as in-progress — same high-level status as ASSIGNED (IN_PROGRESS).

Deposit addresses

The deposit flow is available via userOps=deposit on /v3/swap/quote. The response structure has changed — see the Deposit Addresses Guide for the updated flow.

What changes & stays the same

Base URL changes from https://dedicated-backend.bungee.exchange to https://backend.socket.tech
Auth headers change — use affiliate and x-api-key as issued for your integration
Native token address: 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE
Fee parameters: feeBps and feeTakerAddress stay same
Chain support remains same

API Reference

Full Socket Swap V3 API reference

Get API Access

Request production API credentials

GETTING STARTED

INTEGRATION GUIDES

MIGRATION

RESOURCES

Bungee v1 API → Socket v3 API

Why migrate?

Endpoint changes

Response shape changes

Execution flow changes

Status endpoint changes

Status values

`status` (high-level)

`statusCode` (fine-grained)

Deposit addresses

What changes & stays the same

API Reference

Get API Access

​Why migrate?

​Endpoint changes

​Response shape changes

​Execution flow changes

​Status endpoint changes

​Status values

​status (high-level)

​statusCode (fine-grained)

​Deposit addresses

​What changes & stays the same

API Reference

Get API Access

Why migrate?

Endpoint changes

Response shape changes

Execution flow changes

Status endpoint changes

Status values

`status` (high-level)

`statusCode` (fine-grained)

Deposit addresses

What changes & stays the same