# Creator analytics

Growth dashboards on data that stays consistent. A snapshot a day for every account you track, IDs that stay the same when someone renames, and a timestamp on every data point.

For teams like Beacons, Linktree, Kajabi, Stan, Fourthwall.

## Why teams use Openhandle.

A chart is only as good as its worst night.

### Example: Followers · account 528817151 · renamed Sep 1

**Basic scraper**

| Day | Handle | Followers | Point |
|---|---|---|---|
| Aug 30 | @nasa_hq | 96,412,003 | Plotted |
| Aug 31 | @nasa_hq | 96,430,911 | Plotted |
| Sep 1 | @nasa_hq | not found | Lost |

The account renamed to @nasa. A scraper keyed on the handle loses the account, and a month of history goes with it.

**Openhandle**

| Day | Handle | Followers | Point |
|---|---|---|---|
| Aug 30 | @nasa_hq | 96,412,003 | Plotted |
| Aug 31 | @nasa_hq | 96,430,911 | Plotted |
| Sep 1 | @nasa | 96,449,819 | Plotted |

Same account, same day. Every response carries the permanent platform ID, so the rename is a label change and the chart keeps going.

| Without Openhandle | With Openhandle |
|---|---|
| **Daily snapshots at live prices add up.** Analytics needs a pull per account per day. Paying live rates for data that moved 0.1% is where the budget goes. | **Snapshots from cache.** A 24-hour cache hit costs $0.0005. A cache miss uses the live price. |
| **Handles change, history breaks.** Creators rename. Dashboards keyed on handles lose months of history the day it happens. | **IDs survive renames.** Every response carries the permanent platform ID. Track by ID and a rename never breaks a chart. |
| **Cross-platform charts mix units.** A view, a like, and a share mean different things on each platform. Charts that ignore that are wrong quietly. | **One documented vocabulary.** The metric semantics table says exactly what each metric means per platform and which ones are comparable. |
| **Fetch time is not capture time.** A job that runs late plots yesterday’s number on today’s date. Every late run bends the curve a little. | **Use the capture time.** Each answer shows when we captured it. Use that time to keep late jobs from moving your data points. |

## How a tracking job works.

1. **Track by ID.** Resolve each handle once and store the platform ID. Everything after that is keyed on the ID.
2. **Snapshot daily from cache.** One 24-hour read per account per day. The response says when the data was captured.
3. **Plot the capture time.** Store the capture time as the x-axis, not the fetch time. Your time series stores what was true, and when.

Daily snapshot for one account:

```bash
curl "https://api.openhandle.dev/v1/instagram/profiles/25025320?freshness=24h" \
  -H "Authorization: Bearer $OPENHANDLE_API_KEY"
```

```json
{
  "platform": "instagram",
  "resource": "profile",
  "capturedAt": "2026-09-01T22:40:11Z",
  "source": "cache",
  "data": {
    "id": "25025320",
    "handle": "instagram",
    "metrics": {
      "followers": 690412330,
      "following": 118,
      "posts": 8104
    }
  }
}
```

Served from cache. The capture time is the truth for your time series, not the moment you fetched it.

## Keep your reporting data consistent.

- **Proper invoicing.** Card payment, an invoice for every charge. Nothing prepaid, nothing that expires.
- **A person answers.** Chat directly with the people who build Openhandle through Crisp.

## Documentation

- [Freshness and caching](https://openhandle.dev/docs/concepts/freshness-and-caching)
- [Metric semantics](https://openhandle.dev/docs/concepts/metric-semantics)
- [Identifiers](https://openhandle.dev/docs/concepts/identifiers)