Using the API

Everything you can do on your dashboard's reporting and management pages, you can also do from a script: pull yesterday's numbers into a spreadsheet, pause a campaign from a cron job, create a zone when you launch a new site section. The API lives under /api/v1/ and works the same whether you're an advertiser or a publisher: your key already knows which one you are.

Mint a key

Go to Settings → API keys, give the key a name (so you can tell your keys apart later), and create it. The full key is shown to you exactly once, right after you create it, copy it somewhere safe immediately.

We never store your key, only a fingerprint of it. That means we cannot show it to you again, and we cannot recover it if you lose it. If a key goes missing or you suspect it leaked, revoke it from the same Settings page and mint a new one. Revocation takes effect immediately.

A key starts with prk_. After minting, the list shows only its first few characters (the prefix), when you created it, and when it was last used, enough to recognise a key without exposing it.

Make a request

Send your key as a bearer token in the Authorization header. That header is the only thing that authenticates an API request. A browser cookie never counts, and your key never works on the normal website pages. Start with me, which just tells you which account and role the key carries:

curl -s -H "Authorization: Bearer $YOUR_KEY" https://siliconrelay.com/api/v1/me

{"context": "advertiser", "id": "…", "email": "you@example.com", "display_name": "Acme", "timezone": "Europe/Prague"}

Then pull a report. It's the same report your dashboard's Reporting page shows, as JSON (or add .csv for the spreadsheet export). The numbers reconcile with your dashboard to the row, because both read the same event log:

curl -s -H "Authorization: Bearer $YOUR_KEY" \
  "https://siliconrelay.com/api/v1/report?from=2026-07-01&to=2026-07-24&by=day"

curl -s -H "Authorization: Bearer $YOUR_KEY" \
  "https://siliconrelay.com/api/v1/report.csv?by=day" -o report.csv

Money in every response is in micros, whole integers where 1_000_000 micros is one US dollar, so there are no rounding surprises from floating-point cents.

When something goes wrong

Every error is the same small JSON shape, so a script can branch on the code:

{"error": {"code": "unauthorized", "message": "unknown or revoked API key"}}

• unauthorized (401): a missing, malformed, unknown, or revoked key.
• forbidden (403): a valid key used on an endpoint for the other role (an advertiser key asking for zones, say).
• not_found (404): no such endpoint, or an id your account doesn't own.
• method_not_allowed (405): the endpoint exists, but not for the method you used.
• too_large (413): the request body is over our 16 MB limit and was refused unread. You will not meet this with ordinary use: a full set of ad uploads is well under it.
• invalid (422): the request didn't validate, and the message is the same one the web form would show you.
• rate_limited (429): you've sent too many requests too fast, and a Retry-After header tells you how many seconds to wait. There is a generous per-key limit, so back off and retry.

What the API will never do

The API is read and manage, never pay. No endpoint moves money or changes where your money goes: no deposits, no payout addresses, no payout requests. The worst a leaked key can do is misconfigure campaigns or zones and pull your own reports. It can never redirect a payout or drain a balance. (Deposits and payout settings stay on the website, behind your password.)

What stays stable

Once an endpoint or a field is published, it's a promise: /api/v1 only ever grows. We may add new endpoints, add new fields to existing responses, and add new error codes, but we never remove or rename what's already there, and we never change the shape of a response you already depend on. If we ever needed to make a breaking change, it would live at a new version path (/api/v2) served alongside this one, so your integration keeps working. So it's safe to build against /api/v1 today and leave it running.

Two forward-compatibility habits keep your integration robust: ignore response fields you don't recognise (new ones will appear over time), and treat any error code you don't know as a generic failure. Lists currently return every item. If paging is ever added it will be opt-in, and leaving it off keeps today's behaviour.

Advertisers: Managing creatives over the API picks up where this leaves off: listing a campaign's ads, uploading more, swapping one out, and matching per-ad reporting rows back to the ad that served.

This article is the quick start. The full customer API reference, every endpoint, field, and query parameter, is a separate document. The API keys card in your Settings points you to it when you're ready to go past me and the report.