Tip: For advanced integrations, we recommend using Relay APIs. For simpler use cases, the Relay SDK automates steps and provides helpful callbacks, reducing manual effort.

​
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 quote endpoint, 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). 
// Creating an `EIP-191` signature involves signing a message. 
// When you receive a `signatureKind: "eip191"` from the API, you will sign the value associated with the `message` property. 
// In the case below, the message `Sign in to Blur...` will be signed, and later posted to the API.
// The step item also contains a `post` object detailing the endpoint to post the signed message to.
const message = {
    "signatureKind": "eip191",
    "message": "Sign in to Blur\n\nChallenge: e2483db1d9d66d2b77f47a8dfa13a15a0e7df5aee2287ade4bf313d6d4bdd0e0"
}

const eip191Message = "\x19Ethereum Signed Message:\n" + message.message.length + message.message;
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
waitingDeposit tx for the request is yet to be indexed
pendingDeposit tx was indexed, now the fill is pending
successRelay completed successfully
failureRelay failed, attempting to refund
refundFunds were refunded due to failure

​
SDK Reference

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