Skip to main content
The Reporting API returns the same campaign analytics shown on the Linkrunner dashboard.

Base URL

Authentication

Pass your project’s server key in the linkrunner-key header. This is the same key used by other /api/v1 endpoints. Find it under Settings → Data APIs:

Postman collection

Download the Postman collection. Import it into Postman, set the linkrunner_key collection variable to your key, and run any request.

Rate limit and freshness

  • 1 request per minute per API key (429 with Retry-After: 60 when exceeded).
  • 30 req/sec per source IP (shared across all /api/v1 endpoints).
  • Underlying analytics refresh on roughly the same cadence, so cache responses for at least 60 seconds.

Endpoint

Do not call the docs page URL (/api-reference/reporting-campaigns) as the API endpoint. The API path is /api/v1/reporting/campaigns.

Example request

Response

pagination.total is the number of campaigns matching your filters, and pages is total / limit rounded up.
Numeric fields are returned as formatted strings ("3,201", "$12,540.50"). Strip the formatting before doing math: Number(value.replace(/[^0-9.-]/g, "")).

Query parameters

from and to choose the window over which metrics (clicks, installs, revenue, spend) are computed. They do not filter which campaigns are returned: a campaign created after to still appears, with zeros for the window. This matches the dashboard campaign table, where the date picker changes the numbers, not the list. To fetch only campaigns created in a range, see Troubleshooting.
See Event columns below for events, payment_events, unique_user_events, cost_per_event, and active_users.

Event columns

Event columns are opt-in. Name the events you want and the response carries those and no others, which keeps the payload small and the query fast. All five take a comma-separated list. Unknown event names are dropped silently, since they match no rows. Naming an event in any of events, payment_events, cost_per_event or unique_user_events puts its count in the response, because a cost-per value is spend divided by that count and a distinct-user count replaces it. The extra columns are what you add on top:
  • events=Purchase returns custom_events.Purchase and nothing else.
  • cost_per_event=Purchase returns cost_per_custom_events.Purchase and custom_events.Purchase.
  • unique_user_events=Purchase returns custom_events.Purchase whose count is distinct users rather than occurrences.
Send none of them and the response contains no event columns at all: custom_events, payment_events, cost_per_custom_events and cost_per_payment_events all come back as {}. Every other metric (clicks, installs, signups, spend, revenue, ROAS, retention) is unaffected. Find your project’s event names under Dashboard → Events.
This changed on 2026-09-11. Previously the endpoint tried to infer which events you wanted from the saved dashboard column settings of one of your project admins, so the same request returned different events for different projects, changed whenever that person edited their dashboard, and gave no way to tell which events you were looking at. Those settings are no longer read.If you were relying on events appearing without asking for them, add an events= list naming them. If a count dropped, that event was previously being counted per distinct user: add it to unique_user_events as well.

Example: two events, with cost-per and distinct users

Each campaign, ad set and ad creative in the response then carries:
Purchase reports distinct users because it was named in unique_user_events; AddToCart reports total occurrences. Both use the count field, so the parameter you sent is the only thing that tells them apart. payment_events is empty because no revenue types were requested.

Errors

Troubleshooting

This is expected. from and to set the metrics window; they never remove campaigns from the list. To keep only campaigns created in a range, request sort_field=created_at&sort_order=descending, then drop rows client-side once created_at falls before from.
The limit is 1 request per minute per API key. Honor the Retry-After: 60 header and cache responses for at least 60 seconds. The underlying analytics refresh on roughly the same cadence, so polling faster returns the same data.
Compare the same date range and the same view (user_acquisition vs retargeting). The API interprets from and to in your project’s timezone, exactly like the dashboard date picker. If you are doing math on the values, remember they are formatted strings (see the warning under Response).

TypeScript types

Need help? Contact support@linkrunner.io