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 options and their execution boundaries side by side
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.

Graphic: Output fields, fees, and the displayed amount (Mayan)

View full-size image

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.

Mayan: What can the swap widget configuration change? - diagram

View full-size image


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.

Mayan: Completion tracking and refundable orders - illustration

View full-size image

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.

Updated: