Address activity

GET/api/address/{address}/activity

What an address bought and sold (every marketplace), listed and cancelled on raresats.net, extracted, mined and moved, newest first, with filter facets and totals. Transfers and extractions come from the index's per-address history (from the ordinals era) where it has one, read as far as the pages asked for need it; else from the moves it keeps (about 4 weeks); before either, the address's held UTXOs. coverage says which and how far; summary.partial says when the totals cover only the history read so far. Pages follow next (pass it as before), which does not drift when newer activity arrives. Cacheable 15 s. The first page (no before, no to) leads with the address's pending items (pending: true, source: mempool), outside limit, total and the facets; pending=0 leaves them out. A sale here the index shows pending is listed once, as the index's.

Path parameters #

Query parameters #

Example request #

curl 'https://raresats.net/api/address/bc1p5cyxnuxmeuwuvkwfem96lqzszd02n6xdcjrs20cac6yqjjwudpxqkedrcr/activity?types=bought,sold'

const response = await fetch('https://raresats.net/api/address/bc1p5cyxnuxmeuwuvkwfem96lqzszd02n6xdcjrs20cac6yqjjwudpxqkedrcr/activity?types=bought,sold');
const data = await response.json();

import requests

data = requests.get("https://raresats.net/api/address/bc1p5cyxnuxmeuwuvkwfem96lqzszd02n6xdcjrs20cac6yqjjwudpxqkedrcr/activity", params={"types": "bought,sold"}).json()

Response 200 #

Errors #

{error} (a message, no code):

The address page's Activity tab reads this route. One list, newest first, merges:

A transaction that is one of the address's sales is shown once, as the sale; a sale of a bundle names its secondary rows (the other sats sold with its row). A raresats.net purchase shows as pending until its block is read.

Pending. The first page (no before, no to) leads with the address's transactions still in the mempool: sales it is selling or buying, transfers in and out, extractions. Each has pending: true, source: "mempool", first_seen, fee_rate, and no height. They match the type, row and date filters but sit outside limit, total, the facets and summary (pending_total counts them); once mined they come back as ordinary items. A raresats.net purchase the index already shows pending is listed once, as the index's item. pending=0 leaves them out. See Pending.

coverage.transfers is since block N: transfers and extractions are whole from block N, where the index's per-address history starts (the ordinals era, coverage.history_from). Before block N, only the UTXOs the address still holds are listed, as transfer_in items with source: "holdings". Until the index serves the history, transfers cover the moves it keeps, about 4 weeks.

A busy address has tens of thousands of entries, so the history is read lazily: each page reads as much of it as it needs, newest first. Until all of it has been read, coverage.history_complete is false, coverage.loaded_since says how far back it goes so far, and summary.partial is true. In that case the extraction and transfer counts, the facets and total cover the history read so far. Sales and listings are always whole. Type, row and date filters are passed down to the index, so a filtered page skips what cannot match.

facets count each filter's values under the other filters, so a chip can say what choosing it would show. summary totals everything known, whatever the filters.

To page, pass next as before with the same filters. The cursor names the last event shown, so newer activity arriving at the top shifts nothing. While the history is still being read, a page may hold fewer events than limit, even none, with a next that reads further. Keep following next until it is null.

curl 'https://raresats.net/api/address/bc1p5cyxnuxmeuwuvkwfem96lqzszd02n6xdcjrs20cac6yqjjwudpxqkedrcr/activity?types=bought,sold&limit=20'