Affiliate Portal API

The station API gives your traffic and automation systems what the portal shows a person: each network's order for the week, its audio and printable documents, and a way to report what aired. It is JSON over HTTPS, and every call carries a station key.

Base URL

https://affiliates.radioworkflow.com/api/v1

Every path in this reference is under it. The same address serves the OpenAPI 3.1 document, without a key.

Quick start: a first call in five minutes

1. Create a key. Sign in to the portal, open API and MCP (/developers), choose the stations, give it the read and report scopes and copy the secret. It is shown once. Keep it in an environment variable: the samples read AFFILIATE_API_KEY.
2. List your affiliations. Each is one station's relationship with one network, and its id goes in every other path.
3. Read the week. Use the affiliation's id and the Monday of the broadcast week. Note week.epoch, and the id and rev of a unit whose window has closed.
4. Report one time. Send the unit's id and rev, the week's epoch, and the day and time it aired. The answer shows the unit as the network now sees it.

curl -X GET 'https://affiliates.radioworkflow.com/api/v1/affiliations' \
  -H "Authorization: Bearer $AFFILIATE_API_KEY"

curl -X GET 'https://affiliates.radioworkflow.com/api/v1/affiliations/srn-ksmt/weeks/2026-09-21' \
  -H "Authorization: Bearer $AFFILIATE_API_KEY"

# A new Idempotency-Key for every new request. Reuse it only to retry this same request.
IDEMPOTENCY_KEY=$(uuidgen)

curl -X POST 'https://affiliates.radioworkflow.com/api/v1/affiliations/srn-ksmt/weeks/2026-09-21/affidavits' \
  -H "Authorization: Bearer $AFFILIATE_API_KEY" \
  -H 'Content-Type: application/json' \
  -H "Idempotency-Key: $IDEMPOTENCY_KEY" \
  -d '{
  "epoch": 1,
  "items": [
    {
      "unit_id": "u-01oso1x",
      "rev": 1,
      "status": "aired",
      "aired_date": "2026-09-22",
      "aired_at": "07:42"
    }
  ]
}'

Every endpoint page has a Try it panel that runs the call on demo data with no key, so you can see each answer before you write any code.

Every request

• The key as a bearer token: Authorization: Bearer rwaff_k_.... See Authentication.
• Bodies are JSON objects, sent with Content-Type: application/json; a log upload is multipart/form-data.
• The calls that record acknowledgements, affidavits, show certificates and log matches take an Idempotency-Key header: a new one for every request and the same one to retry it, so a retry never records twice. upload-log is not idempotent: sending a file again is a new upload. See Pagination and idempotency.
• A week is its Monday, YYYY-MM-DD. Times are minutes after midnight (0 to 1439) or HH:MM, in the station's time zone.

Every response

• X-Request-Id names the request; quote it when you ask about one.
• RateLimit-Limit, RateLimit-Remaining and RateLimit-Reset report the key's burst bucket. See Rate limits.
• Cache-Control: no-store: answers are never cached.
• A refusal carries a status, a code and one sentence in the error envelope below. See Errors.

{
  "error": {
    "code": "epoch_changed",
    "message": "The week changed since you read it. Read it again, then retry.",
    "epoch": 2
  }
}

What a key cannot do

A key reads and reports; it never signs. Signing a week is an attestation that the affidavits are true, so a person does it in the portal. POST .../sign answers 403 key_cannot_sign for every key.

Assistants and coding agents

• An assistant can use these endpoints as tools through the MCP server, all but upload-log and get-document; over MCP, get-week-audio returns a link to the audio ZIP rather than the audio, and sign-week only returns the link where a person signs.
• A coding agent can read /llms.txt, the index of these pages, or /llms-full.txt, all of them in one file.
• API tools and client generators read the OpenAPI document.

Endpoints