---
title: "Get All Matches"
method: GET
path: "/matches"
tags: ["Matches"]
---

# Get All Matches

`GET /matches`

Retrieve all matches from the database, in descending `slot_no` order. Results are streamed to the client for more efficiency.

Optionally, use `?resolve_hashes` to automatically resolve and include `datum` and `script` associated with hash references, if available. Datums and scripts can otherwise be fetched using the [_Get Datum by Hash_](#tag/Datums/paths/~1datums~1{datum-hash}/get) and [_Get Script by Hash_](#tag/Scripts/paths/~1scripts~1{script-hash}/get) endpoints respectively.

Note that it is generally a bad idea to fetch **ALL matches** for indexes built off permissive patterns (e.g. `*`), for the server will yield a large response.

## Query parameters

- `order` 'most_recent_first' | 'oldest_first' — Order results by their location on-chain. By default, most recent results are returned first (i.e. by descending `created_at.slot_no`). Within a same slot, results are ordered in function of their position in the block (i.e. `transaction_index`).
- `created_after` union
  - integer — Only fetch results that were created at and after the given slot.
  - string — Only fetch results that were created at and after the given point. This fails if the provided point doesn't exist. It is handy to fetch a collection of results by pages while ensuring that the collection isn't being altered to due alternative chain forks being adopted. The last known fetch point can be used as starting point for the next range. Points are defined in the usual format (same as the command-line): ``` ┏━━━━━━━━━━━━━┓ ╭───╮ ┏━━━━━━━━━━━━━┓ POINT = ╾─┫ SLOT-NUMBER ┣─┤ . ├─┫ HEADER-HASH ┣─╼ ┗━━━━━━━━━━━━━┛ ╰───╯ ┗━━━━━━━━━━━━━┛ ┏━━━━━━━━━━━┓ HEADER-HASH = ╾─┫ 64 HEXDIG ┣───────────────────╼ ┗━━━━━━━━━━━┛ ┏━━━━━━━━━━┓ SLOT-NUMBER = ╾─┫ 1* DIGIT ┣────────────────────╼ ┗━━━━━━━━━━┛ ``` For example: `5999990.dca1e44765b9f80c8b18105e17de90d4a07e4d5a83de533e53fee32e0502d17e`
- `spent_after` union
  - integer — Only fetch results that were spent at and after the given slot.
  - string — Only fetch results that were spent at and after the given point. This fails if the provided point doesn't exist. It is handy to fetch a collection of results by pages while ensuring that the collection isn't being altered to due alternative chain forks being adopted. The last known fetch point can be used as starting point for the next range. Points are defined in the usual format (same as the command-line): ``` ┏━━━━━━━━━━━━━┓ ╭───╮ ┏━━━━━━━━━━━━━┓ POINT = ╾─┫ SLOT-NUMBER ┣─┤ . ├─┫ HEADER-HASH ┣─╼ ┗━━━━━━━━━━━━━┛ ╰───╯ ┗━━━━━━━━━━━━━┛ ┏━━━━━━━━━━━┓ HEADER-HASH = ╾─┫ 64 HEXDIG ┣───────────────────╼ ┗━━━━━━━━━━━┛ ┏━━━━━━━━━━┓ SLOT-NUMBER = ╾─┫ 1* DIGIT ┣────────────────────╼ ┗━━━━━━━━━━┛ ``` For example: `5999990.dca1e44765b9f80c8b18105e17de90d4a07e4d5a83de533e53fee32e0502d17e`
- `created_before` union
  - integer — Only fetch results that were created at and before the given slot.
  - string — Only fetch results that were created at and before the given point. This fails if the provided point doesn't exist. It is handy to fetch a collection of results by pages while ensuring that the collection isn't being altered to due alternative chain forks being adopted. The last known fetch point can be used as starting point for the next range. Points are defined in the usual format (same as the command-line): ``` ┏━━━━━━━━━━━━━┓ ╭───╮ ┏━━━━━━━━━━━━━┓ POINT = ╾─┫ SLOT-NUMBER ┣─┤ . ├─┫ HEADER-HASH ┣─╼ ┗━━━━━━━━━━━━━┛ ╰───╯ ┗━━━━━━━━━━━━━┛ ┏━━━━━━━━━━━┓ HEADER-HASH = ╾─┫ 64 HEXDIG ┣───────────────────╼ ┗━━━━━━━━━━━┛ ┏━━━━━━━━━━┓ SLOT-NUMBER = ╾─┫ 1* DIGIT ┣────────────────────╼ ┗━━━━━━━━━━┛ ``` For example: `5999990.dca1e44765b9f80c8b18105e17de90d4a07e4d5a83de533e53fee32e0502d17e`
- `spent_before` union
  - integer — Only fetch results that were spent at and before the given slot.
  - string — Only fetch results that were spent at and before the given point. This fails if the provided point doesn't exist. It is handy to fetch a collection of results by pages while ensuring that the collection isn't being altered to due alternative chain forks being adopted. The last known fetch point can be used as starting point for the next range. Points are defined in the usual format (same as the command-line): ``` ┏━━━━━━━━━━━━━┓ ╭───╮ ┏━━━━━━━━━━━━━┓ POINT = ╾─┫ SLOT-NUMBER ┣─┤ . ├─┫ HEADER-HASH ┣─╼ ┗━━━━━━━━━━━━━┛ ╰───╯ ┗━━━━━━━━━━━━━┛ ┏━━━━━━━━━━━┓ HEADER-HASH = ╾─┫ 64 HEXDIG ┣───────────────────╼ ┗━━━━━━━━━━━┛ ┏━━━━━━━━━━┓ SLOT-NUMBER = ╾─┫ 1* DIGIT ┣────────────────────╼ ┗━━━━━━━━━━┛ ``` For example: `5999990.dca1e44765b9f80c8b18105e17de90d4a07e4d5a83de533e53fee32e0502d17e`
- `policy_id` string
- `asset_name` string
- `transaction_id` string — A blake2b-256 hash digest of a transaction body.
- `output_index` integer — Restrict results to a particular output index of a transaction. This parameter can't be used alone and must be provided alongside a `transaction_id`.

## Response `200`

OK

## Other responses

- `304` — Not Modified Returned when a `If-None-Match` request header matches the current `ETag` for the response. This is meant to provide efficient caching and polling. The `ETag` corresponds to the most recent block header hash processed by Kupo.

---

[API](https://skmtc.net/txpipe/apis/kupo.md) · [All operations](https://skmtc.net/txpipe/apis/kupo/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/txpipe/kupo/revisions/33786c4eb0ff/schema)