Learn how to interpret the status of transactions and individual transfer steps from the Skip Go API’s /v2/tx/status endpoint to provide accurate feedback to users.
/v2/tx/status
endpoint of the Skip Go API. Refer to the API Reference for detailed schema information./v2/tx/status
API response to determine if a transaction (and each of its constituent transfers) is pending, successful, has encountered an error, or has been abandoned.
This approach is useful for driving UI elements such as progress indicators, status messages, and error displays in your application.
/v2/tx/status
Response/v2/tx/status
endpoint, illustrating some of the key fields discussed in this guide:
/v2/tx/status
API response object:
state
field in the response.'STATE_COMPLETED_SUCCESS'
: The entire transaction finished successfully.'STATE_COMPLETED_ERROR'
: The transaction finished, but an error occurred.'STATE_ABANDONED'
: The transaction was abandoned (e.g., due to timeout or user action).next_blocking_transfer.transfer_sequence_index
field (if next_blocking_transfer
exists in the response).transfer_sequence
array.transfer_sequence
array of the response, you can determine its individual status:
next_blocking_transfer.transfer_sequence_index
(if next_blocking_transfer
exists).state
is not STATE_COMPLETED_ERROR
or STATE_ABANDONED
).next_blocking_transfer.transfer_sequence_index
(if next_blocking_transfer
exists - it is typically null
if the overall state
is terminal (e.g., STATE_COMPLETED_SUCCESS
, STATE_COMPLETED_ERROR
, or STATE_ABANDONED
) as the transaction is no longer actively blocked or has finished successfully).state
field) is STATE_COMPLETED_ERROR
or STATE_ABANDONED
.STATE_COMPLETED_ERROR
and this is the last operation in the sequence, it is also considered to be in an error state.state
is STATE_COMPLETED_ERROR
, it’s also crucial to inspect the specific error
object within each individual transfer step in the transfer_sequence
(e.g., step.ibc_transfer.packet_txs.error
, step.cctp_transfer.error
, etc.). This will help pinpoint the exact leg(s) that encountered issues, as the next_blocking_transfer
might be null
if the transaction reached a terminal error state rather than getting stuck midway.state
field) is STATE_COMPLETED_SUCCESS
, then all operations in the sequence are considered successful.next_blocking_transfer.transfer_sequence_index
(if next_blocking_transfer
exists - see note above about it typically being null
in terminal states) is assumed to have completed successfully.transfer_asset_release
)transfer_asset_release
object in the /v2/tx/status
response provides crucial information about where the user’s assets have ultimately landed or are expected to be claimable, especially in scenarios involving swaps or complex routes.
Key fields include:
chain_id
: The chain ID where the assets are located.denom
: The denomination (asset identifier) of the released assets.amount
: The quantity of the released assets.released
: A boolean indicating if the assets have been definitively released to the user (e.g., available in their wallet or claimable). If false
, it might indicate that assets are still in a contract or awaiting a final step for release.transfer_asset_release
field is particularly important for determining the location and state of the user’s funds. For a comprehensive understanding of how assets are handled in different failure scenarios (e.g., pre-swap vs. post-swap failures), please refer to our detailed guide on Handling Cross-Chain Failure Cases.