We recommend using the SDK over our APIs. The SDK will iterate the steps and return useful callback information.

Step Execution using the API

When executing orders using the API directly, there are often multiple steps, like submitting a deposit transaction to the solver or signing a message. These steps differ based on the desired action and best route to execute the action. To make this simple, you can use the execute endpoints, which return the exact steps that you need to follow, including descriptions that you can display to users.

The flow looks like this:

Fetching Steps

Call the Get Quote API to start your execution.

Iterate Through Steps

Iterate through the steps and the items within a step, taking the necessary actions. Steps with no items, or an empty array of items, should be skipped. If step item data is missing then polling the api is necessary.

Executing Steps

As mentioned above each step contains an array of one or more items. These items need to be iterated and completed depending on the kind of step (signature or transaction).

Checking the fill status

After a step is signed or submitted you should check on the progress of the fill

Success!

Once all the steps are complete you can consider the action complete and notify the user.

Signature Step

A message that needs to be signed. Every signature comes with sign data and post data. The first action we need to take is to sign the message, keep in mind the signatureKind and use the appropriate signing method. Refer to your crypto library of choice on how to sign (viem, web3, etc).

Posting the data

After the message is signed the second action is to submit the post body to the endpoint provided in the post data. You’ll also need to provide the signature that was generated from the sign data as a query parameter. If the request is successful we can mark the step item as complete locally.

The design pattern of this API is completely generic, allowing for automatic support of new types of liquidity without needing to update the app. This data can be fed directly into an Ethereum library such as viem, making it easy to sign and submit the exact data that is needed.

Transaction Step

A transaction that needs to be submitted onchain. After the transaction is submitted onchain you can poll the step items check endpoint. The endpoint will return a status which when successful will return ‘success’. The step item can then be successfully marked as complete. Note that the transaction step item contains a chainId for which the transaction should be submitted on.

Steps Example

Below is an example of steps you’ll encounter in the wild when working with the API.

{
  "steps": [
    {
      "id": "deposit",
      "action": "Confirm transaction in your wallet",
      "description": "Deposit funds for executing the calls",
      "kind": "transaction",
      "items": [
        {
          "status": "incomplete",
          "data": {
            "from": "0x03508bB71268BBA25ECaCC8F620e01866650532c",
            "to": "0xf70da97812cb96acdf810712aa562db8dfa3dbef",
            "data": "0x58109c",
            "value": "995010715204139091",
            "maxFeePerGas": "18044119466",
            "maxPriorityFeePerGas": "2060264926",
            "chainId": 1,
            "gas": 21064
          },
          "check": {
            "endpoint": "/intents/status?requestId=0x341b28c6467bfbffb72ad78ec5ddf1f77b8f9c79be134223e3248a7d4fcd43b6",
            "method": "GET"
          }
        }
      ]
    }
  ],
  "fees": {
    "gas": "384398515652800",
    "gasCurrency": "eth",
    "relayer": "-4989478842712964",
    "relayerGas": "521157287036",
    "relayerService": "-4990000000000000",
    "relayerCurrency": "eth"
  },
  "breakdown": {
    "value": "1000000000000000000",
    "timeEstimate": 10
  },
  "balances": {
    "userBalance": "54764083517303347",
    "requiredToSolve": "995010521157287036"
  }
}

Along with the steps you’ll see that the following objects are returned: fees, breakdown and balances. Information about fees is detailed here. Breakdown pertains to time estimation for the execution, broken down by value. The balances object is in regards to the user and how much they require to solve for the execution.

Checking the fill status

Along with the step data there’s an optional check object. You can use this object to check if the status of the transaction is complete. The object details the method and the endpoint to request. You should poll this until the endpoint returns success.

{
    "check": {
        "endpoint": "/intents/status?requestId=0x341b28c6467bfbffb72ad78ec5ddf1f77b8f9c79be134223e3248a7d4fcd43b6",
        "method": "GET"
    }
}

The check api will always return a status, the expected statuses are as follows:

StatusDescription
refundExecution was refunded on the origin chain unless refundOrigin parameter is set to false, in which case the refund is made on the destination chain
delayedIf the time pending is 2x the p50 fill time, we mark the request as delayed
waitingWaiting for a deposit
failureThe fill has failed and was not refundable, check the details property for more information on the failure
pendingFill is currently pending
successFill was successfully processed

SDK Reference

To review the official way the SDK handles execution, please refer to the executeSteps file which implements executing steps detailed above.