Mayan integration with the API, SDK, and swap widget
Mayan offers a swap SDK for custom interfaces, direct API access for integrations building their own transactions, and a configurable widget for embedded swaps. The SDK wraps quoting and prepares transactions for supported source chains, reducing chain-specific construction work. Direct API access suits unsupported programming languages or a backend that only needs quotes. The widget supplies the swap interface and exposes settings for supported chains, token lists, appearance, and referral fees. Choosing among them changes which parts of transaction construction and presentation the application owns. It doesn't turn a quote, signature, or submitted transaction into evidence of destination delivery.
Integration options and their execution boundaries
The widget supplies a ready-made interface; the SDK supports a custom one while constructing swap transactions. Direct API access leaves transaction construction with the application. Source-chain differences also matter inside the SDK, especially when a helper returns an unsigned transaction.
| Integration option | What it provides | Execution constraints |
|---|---|---|
| Swap widget | Embedded cross-chain swap interface | Uses the supported chains and tokens selected in its configuration. |
| EVM SDK execution |
swapFromEvm
|
ERC-20 inputs need Forwarder spending authorization. |
| Solana SDK execution |
swapFromSolana
|
Uses a Solana transaction-signing callback. |
| Sui SDK construction |
createSwapFromSuiMoveCalls
|
The app signs and broadcasts the returned transaction. |
| Quote-only API access | Route and amount data for a backend | Quote retrieval doesn't submit a swap. |
| Direct API execution | Transactions built by the application | The app handles chain-specific construction and route branching. |
These options share the underlying protocol. The integration surface alone doesn't establish which route a token pair receives; the quote supplies that distinction.
When does the SDK fit a custom swap interface?
The SDK lets an application keep its own screens while using chain-specific transaction builders wrapped around the Quote API. The package is
@mayanfinance/swap-sdk
, and
fetchQuote
retrieves the available routes for a pair.
EVM and Solana integrations use
swapFromEvm
and
swapFromSolana
, respectively.
The Sui helper
createSwapFromSuiMoveCalls
returns a transaction the application must sign and broadcast.
For Sui, SDK v15 requires
@mysten/sui
v2 with a Core API client. Sui-to-HyperCore transfers are temporarily disabled; the helper rejects that destination.
The EVM helper
getSwapFromEvmTxPayload
returns a payload without sending it. On Solana,
createSwapFromSolanaInstructions
returns instructions the app can compose into its own transaction. These paths retain SDK construction support while leaving the final send with the application.
For CommonJS
require()
, documented minimums are Node 20.19 within the 20.x release line and 22.12 within 22.x. Incompatible older runtimes fail with
ERR_REQUIRE_ESM
because the package loads ESM-only dependencies at import. ESM imports work on modern runtimes.
Direct API access transfers transaction work to the app
Direct API access suits a backend that only fetches quotes or an execution stack outside the SDK's supported language. When that integration also executes swaps, it must construct transactions and arrange signing for each source chain.
The selected quote's
type
determines the execution contract and required route-specific fields. Values include
SWIFT
,
MCTP
,
FAST_MCTP
, and
WH
. An array can contain different route types, so branching must use the actual selected object.
ERC-20 inputs on EVM require spending authorization for the Forwarder before the swap. An allowance must cover at least
effectiveAmountIn64
; a token supporting EIP-2612 can use a permit signature instead. Native-token inputs don't need this approval.
Direct integrations also encode referrer addresses and verify they match the quote. Solana instructions and Sui Move calls remain chain-specific construction work. A successful quote response supplies execution data; it doesn't replace these responsibilities.
Output fields, fees, and the displayed amount
A quote separates an expected output from a minimum output and the minimum remaining after relayer fees. Those fields answer different interface questions, so a single unlabeled number can obscure what the user would receive.
expectedAmountOut
represents the quoted expectation, while
minAmountOut
is the output floor. The
minReceived
field gives the minimum output after relayer fees have been deducted. The quote also carries
protocolBps
and
referrerBps
, which identify fees applied to that particular option.
For a Swift quote with
swiftAuctionMode
set to
3
,
expectedAmountOut
is the exact settlement amount.
etaSeconds
expresses estimated settlement time in seconds, while
clientEta
supplies a display string. Neither proves the order has completed.
What can the swap widget configuration change?
The widget builder configures supported chains, token lists, colors, and overall appearance, alongside referrer fees and receiving addresses. Selecting a chain or token for display doesn't establish liquidity for a proposed swap. The widget remains an integration surface, with execution depending on the supported options available for the requested pair.
Route availability and gas belong to the selected quote
Route controls determine which families the quote request allows, while returned options establish which routes are available for the pair. The flags
swift
,
mctp
,
fastMctp
, and
wormhole
enable or disable those families. Omitting them allows all; it doesn't guarantee an option from each one.
The selected quote's
gasless
field, when true, means a relayer submits the transaction and pays its gas after the user signs a message. An interface can't infer that property from general support for gas abstraction. Zaps extend a swap with destination actions, including deposits and staking; selecting an integration surface alone doesn't specify that action. Custom flows therefore need to distinguish the requested asset movement from any destination operation attached to it.
Completion tracking and refundable orders
The Explorer API reports whether an order is in progress, completed, or refunded, allowing a custom interface to distinguish submission from destination delivery. Its
clientStatus
field exposes
INPROGRESS
,
COMPLETED
, and
REFUNDED
. The first remains open; the other two are terminal states with different outcomes.
COMPLETED
means destination delivery, and
toAmount
identifies what actually arrived. A gasless
swapFromEvm
call returns an order hash, which the same tracking interface accepts. The returned identifier locates the order; its status establishes the outcome.
deadline64
marks the point after which an order cannot be filled and becomes refundable. Refund eligibility doesn't confirm a completed refund. On Swift, a source-chain conversion can mean a refund returns the locked asset, typically USDC or ETH, instead of the original input token. Show the refunded asset and amount, along with the refund relayer fee returned in the quote.
Still have questions?
Can the Quote API return every available route?
Setting fullList to true requests all available quote options without sorting them. The default response contains at most two options: the fastest and best-return quotes. If one option satisfies both criteria, only one appears. A custom interface can sort the full list using etaSeconds and expectedAmountOut.
Why does the API distinguish amountIn from amountIn64?
amountIn expresses the input in human-readable token units, while amountIn64 expresses it in the token's smallest base units. An integration must supply an input amount in one of these formats. Keeping the formats distinct prevents the amount's representation from changing its intended token quantity.
Is an API key compulsory for a small frontend integration?
An API key is optional for ordinary frontend quote requests with modest volume. Public access remains subject to per-IP rate limits. A key can raise that limit; using the SDK or direct API doesn't by itself remove the request limit.
Which address receives an integration's referral fee?
The receiving address depends on the chain where the referral fee settles. The SDK accepts referrerAddresses keyed by network type, using evm, solana, and sui entries. Direct integrations must encode addresses consistently with the quote; a single assumed recipient format doesn't cover every supported network type.
Does support for a chain apply to both transfer directions?
Source and destination availability are separate properties in the chain configuration. originActive identifies source-chain support, while destinationActive identifies destination-chain support. The relevant flag must be active for the direction the interface offers; a chain's presence in the configuration alone doesn't establish both directions.
Must tokens appear in the API's whitelist to be routable?
A token with a contract address can be routable without appearing in the whitelist, provided liquidity supports the requested transfer. The list supplies convenient token discovery rather than an exhaustive execution boundary. Supplying a token address doesn't remove the need for liquidity on the relevant chains.
How does a destination gas drop differ from gasless execution?
A gas drop delivers native gas to the recipient on the destination chain. For a gasless quote, a relayer submits the transaction and pays its gas on the user's behalf. These settings address different sides of the transfer, so requesting destination gas doesn't establish that the source transaction is gasless.
Where does the API express the slippage tolerance?
The v3 Quote API accepts slippageBps in basis points, with a documented maximum of 500 basis points, equivalent to 5%. The alternative slippage parameter expresses the tolerance as a decimal. These fields describe the requested slippage tolerance; they don't state the protocol or referral fee.