Get orders of one user paginated.
The orders are sorted by their creation date descending (newest orders first).
To enumerate all orders start with offset 0 and keep increasing the
offset by the total number of returned results. When a response
contains less than limit the last page has been reached.
Related docs:
Path Parameters
20 byte Ethereum address encoded as a hex with 0x prefix.
"0x6810e776880c02933d47db1b9fc05908e5386b96"
Query Parameters
The pagination offset. Defaults to 0.
The pagination limit. Defaults to 10. Maximum 1000. Minimum 1.
Response
The orders.
see OrderParameters::sellToken
"0x6810e776880c02933d47db1b9fc05908e5386b96"
see OrderParameters::buyToken
"0x6810e776880c02933d47db1b9fc05908e5386b96"
see OrderParameters::sellAmount
"1234567890"
see OrderParameters::buyAmount
"1234567890"
see OrderParameters::validTo
see OrderParameters::feeAmount
"1234567890"
see OrderParameters::kind
buy, sell see OrderParameters::partiallyFillable
How was the order signed?
eip712, ethsign, presign, eip1271 A signature.
"0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
This field comes in two forms for backward compatibility. The hash form will eventually stop being accepted.
"{\"version\":\"0.9.0\",\"metadata\":{}}"
Creation time of the order. Encoded as ISO 8601 UTC.
"2020-12-03T18:35:18.814523Z"
The class of the order (market, limit, or liquidity). Determines how fees are handled.
market, limit, liquidity The address that signed the order and owns it. For regular orders, this is the trader. For EIP 1271 orders, it's the respective contract (see onchainUser for the actual trader).
"0x6810e776880c02933d47db1b9fc05908e5386b96"
Unique identifier of the order. Computed as the EIP-712 hash of the order data combined with the owner address and valid_to timestamp.
"0xff2e2e54d178997f173266817c1e9ed6fee1a1aae4b43971c53b543cffcc2969845c6f5599fbb25dbdd1b9b013daf85c03f3c63763e4bc4a"
The total amount of sellToken that has been transferred from the user for this order so far.
"1234567890"
The total amount of sellToken that has been transferred from the user for this order so far minus tokens that were transferred as part of the signed fee of the order. This is only relevant for old orders because now all orders have a signed fee of 0 and solvers compute an appropriate fee dynamically at the time of the order execution.
"1234567890"
The total amount of buyToken that has been executed for this order.
"1234567890"
[DEPRECATED] The total amount of the user signed fee that have been executed for this order. This value is only non-negative for very old orders.
"1234567890"
Has this order been invalidated?
Order status.
presignaturePending, open, fulfilled, cancelled, expired The address of the CoW Protocol settlement contract that this order is valid for. Orders are only valid on the settlement contract they were signed for.
"0x6810e776880c02933d47db1b9fc05908e5386b96"
see OrderParameters::receiver
"0x6810e776880c02933d47db1b9fc05908e5386b96"
see OrderParameters::sellTokenBalance
erc20, internal, external see OrderParameters::buyTokenBalance
erc20, internal If set, the backend enforces that this address matches what is decoded as the signer of the signature. This helps catch errors with invalid signature encodings as the backend might otherwise silently work with an unexpected address that for example does not have any balance.
"0x6810e776880c02933d47db1b9fc05908e5386b96"
Orders can optionally include a quote ID. This way the order can be linked to a quote and enable providing more metadata when analysing order slippage.
May be set for debugging purposes. If set, this field is compared to what the backend internally calculates as the app data hash based on the contents of appData. If the hash does not match, an error is returned. If this field is set, then appData MUST be a string encoding of a JSON object.
"0x0000000000000000000000000000000000000000000000000000000000000000"
If set to true, full sell amount will be checked during allowance and balance checking. This will ensure the account has correct allowance and available balance for the order to be created.
Unused field that is currently always set to null and will be removed in the future.
"1234567890"
Liquidity orders are functionally the same as normal smart contract orders but are not placed with the intent of actively getting traded. Instead they facilitate the trade of normal orders by allowing them to be matched against liquidity orders which uses less gas and can have better prices than external liquidity.
As such liquidity orders will only be used in order to improve settlement of normal orders. They should not be expected to be traded otherwise and should not expect to get surplus.
Additional data specific to ethflow orders. Only present for orders placed through the EthFlow contract, which allows trading native ETH directly without wrapping to WETH first.
This represents the actual trader of an on-chain order.
ethflow orders
In this case, the owner would be the EthFlow contract and not the actual trader.
"0x6810e776880c02933d47db1b9fc05908e5386b96"
There is some data only available for orders that are placed on-chain. This data can be found in this object.
Total fee charged for execution of the order. Contains network fee and protocol fees. This takes into account the historic static fee signed by the user and the new dynamic fee computed by solvers.
"1234567890"
Token the executed fee was captured in.
"0x6810e776880c02933d47db1b9fc05908e5386b96"
Full appData, which the contract-level appData is a hash of. See OrderCreation for more information.
If the order was created with a quote, this field contains the original quote data for reference. Includes gas estimation and pricing information captured at the time of quoting, which can be used to analyze order execution and calculate fees.
Optional pre and post interactions associated with the order. Pre-interactions are executed before the order's trade, and post-interactions are executed after.