Pricing

Spate charges in credits. You pay full price the first time you pull a given URL in a week, then a small access fee for every subsequent call within that same week — so a dashboard you refresh daily costs roughly the same as one you refresh once a week.

Credits per endpoint

The table below shows the typical weekly cost for popular use cases, assuming optimized usage (one refresh per week with light repeat reads).

The top5 limit is included for previewing payloads during development.

Endpoint	Credits / refresh / URL¹
All Beauty Trends, US, Pop Index	50,000
Top 5 Beauty Trends, US, Pop Index	35
All Beauty Brands, US, Pop Index	60,000
Top 5 Beauty Brands, US, Pop Index	35
All Skincare Trends, US, Pop Index	10,000

¹ Given optimized usage of the API. Additional credits may be consumed for repeated calls. See How credits work below.

How credits work

Each URL has a weekly refresh window. Your first call to that URL inside the window pays the base rate, which unlocks and prepares fresh data for the week. Every subsequent call to the same URL in the same window pays only a small repeat access fee.

Endpoint	Base (first call / week)	Repeat (every later call)
All Beauty Trends, US, Pop Index	50,000	10
All Beauty Brands, US, Pop Index	60,000	10

Tip

Total weekly cost for one URL = base + (extra_calls × repeat). For one refresh per week with no repeats, Trends by Cat1 costs 50,000 credits.

One window per URL

The window is per-URL, not per-account. /us/{id_A} and /us/{id_B} are different URLs and each pay their own base. The window resets weekly — a call on Monday and another the following Tuesday both pay the base rate.

Examples

Dashboard refreshed monthly vs. weekly

If your dashboard pulls Trends by Cat1, Pop Index for one region/category and refreshes:

• Monthly → one base call per month per URL. ~50,000 credits / month.
• Weekly → four or five base calls per month (depending on the calendar). ~200,000 to 250,000 credits / month.

Repeat-rate calls during the week (dashboard reloads, multiple viewers, occasional testing) are negligible at 10 credits each.

A typical week of calls

Here’s what two consecutive weeks look like for a single URL.

The window runs Tuesday through Monday.

Credits charged per call

Week 5 (Tue → Mon)
  Tue  GET /v1/cat1/trends/all/popindex/us/beauty   → 50,000 credits  (base)
  Wed  GET /v1/cat1/trends/all/popindex/us/beauty   →     10 credits  (repeat)
  Wed  GET /v1/cat1/trends/all/popindex/us/beauty   →     10 credits  (repeat)
  Thu  GET /v1/cat1/trends/all/popindex/us/beauty   →     10 credits  (repeat)
   …
  Mon  GET /v1/cat1/trends/all/popindex/us/beauty   →     10 credits  (repeat)

Week 6 (Tue → Mon)
  Tue  GET /v1/cat1/trends/all/popindex/us/beauty   → 50,000 credits  (base)

Every response includes a credits_used field reflecting what that specific call cost.

Log it to track spend without surprises.

Cost-saving tips

Cache on your side

Data within a weekly window doesn’t change. Cache responses in your app or warehouse; caching cuts latency and saves credits.

Align refreshes early

Schedule your weekly refresh on Tuesday — earlier in the window means more downstream readers benefit from the repeat rate before the next reset.

Prototype with the sample

Use the top5 limit while you’re wiring things up — same response shape, lighter payload.

Watch credits used

Every response includes a credits_used field. Aggregate it per endpoint to build a real-time spend dashboard.

Next steps

Quick start Generate a key and make your first authenticated request.