tags input that gets recorded on the request’s usage log. Tags are yours to define — common uses are environment (production, staging), team or tenant (team-alpha, customer-42), or feature (onboarding-flow, nightly-refresh). You can then filter the usage tab of your dashboard by any tag to see credits burned by that slice.
Tags are purely for observability. They don’t change response shape, pricing, caching, or rate limits.
When to use tags
Reach for tags when a single API key serves multiple workloads and you need to see which one is spending credits:- Split spend between
productionandstagingon the same key. - Attribute usage to internal teams, tenants, or customers.
- Compare cost of one code path (say,
nightly-batch) against another (user-triggered). - Track cost of an experiment or migration before you commit.
How to send tags
Tags are optional on every endpoint except/v1/monitors/* and /v1/admin/*. On monitors, tags keeps its existing meaning — tags belong to the monitor resource itself, and every run of a tagged monitor automatically carries those tags to its usage log.
The shape depends on the HTTP method:
| Request type | Where tags go | Format |
|---|---|---|
POST (JSON body) | tags field in the body | Array of strings |
GET and POST /v1/parse | tags query parameter | Comma-separated string, or repeated ?tags= params |
- Up to 20 tags per request.
- Each tag is 1–50 characters.
- Duplicates across body and query are deduplicated.
- Invalid tags return
400 INPUT_VALIDATION_ERROR.
POST example
GET example
Filter usage by tag
Once a tagged request is logged, open the usage tab of your dashboard and filter by any tag to see the credits and request count attributed to that slice. Monitor runs on a monitor that has resource-leveltags also appear under those tags, so you can view monitor and non-monitor spend side by side.
Related
- Handle Rate Limits — pace requests once you’ve identified which tag is burning quota.
- Integration Best Practices — patterns to keep spend predictable.