Developers
Getting Started

Quickstart

Connect the right Rad TV account, verify it, and make your first useful API call.

This is the canonical path from discovering the Rad TV API to a verified first call. At the end, you will know which account and channel your integration controls and you will have read that channel's latest content.

The API supports publishing and managing Rad-hosted video, reading channels and catalogs, recording engagement, working with YouTube references, and connecting AI agents through MCP. All requests use https://api.rad.live.

1. Confirm your account is eligible

Sign in to Rad TV and check Billing. Developer access requires an active eligible Rad TV subscription, including an active trial. Your account also needs a channel before it can create or publish content.

Standard API operations do not require Creator+. Creator+ is required only for premium intelligence and processing features such as AI enhancement and virality prediction.

Expected result: Billing shows an active subscription, and the account you intend to connect has a channel.

If it does not: Activate or manage your subscription. If the API later returns no channel, create or finish setting up your channel on Rad TV, then repeat the verification step below.

2. Choose how to authenticate

MethodChoose it whenTradeoff
API keyYou own the account and are building a script, backend service, or private integrationFastest setup, but your service must store the long-lived secret securely
OAuth 2.1 with PKCEAn MCP client acts for another Rad TV userThe user can approve and revoke MCP access without sharing a key, but the client must implement the OAuth redirect and token lifecycle

This quickstart uses an API key because the examples call GraphQL directly. OAuth access tokens currently authenticate MCP connections and their upload handoffs; they do not replace an API key at the GraphQL endpoint. For delegated MCP access, use the OAuth 2.1 flow and call verify_connection through the connected MCP client.

Expected result: You have selected API key authentication for a private integration or OAuth for delegated access.

If you are unsure: Use an API key when you control both the integration and Rad TV account or need direct GraphQL access. Use OAuth when another person must grant an MCP client access.

3. Connect the intended account

For an API key, sign in as the intended Rad TV account, open Developer Settings, select Generate API Key, and copy the key into your secret store. Developer Settings can reveal and copy the current key again. Selecting Regenerate later invalidates the previous key immediately.

For OAuth, sign in as the intended account before approving the consent screen. Verify the displayed identity rather than assuming that the browser is using the right session.

Keep API keys and OAuth tokens out of source control, browser code, logs, and screenshots. Store them in a secrets manager or local environment variable.

Expected result: You have a Bearer credential issued for the account you mean to control.

If it is the wrong account: For an API key, sign in to the correct account and generate its key. For OAuth, revoke or log out of the MCP session, sign out of Rad TV, sign in to the correct account, and connect again. See Recover, switch, or disconnect.

4. Verify the user and channel

GraphQL uses the verifyConnection query with an API key to confirm authentication and identify the connected user, channel, subscription, and permissions.

curl -X POST https://api.rad.live/graphql \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "query": "{ verifyConnection { authenticated user { id username email } channel { id name } subscription { plan state } permissions youtubeConnected serverVersion } }"
  }'
const response = await fetch('https://api.rad.live/graphql', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Authorization': 'Bearer YOUR_API_KEY',
  },
  body: JSON.stringify({
    query: `{
      verifyConnection {
        authenticated
        user { id username email }
        channel { id name }
        subscription { plan state }
        permissions
        youtubeConnected
        serverVersion
      }
    }`,
  }),
});

const { data, errors } = await response.json();
if (errors) throw new Error(errors.map(({ message }) => message).join('; '));
console.log(data.verifyConnection);
import requests

response = requests.post(
    "https://api.rad.live/graphql",
    headers={
        "Content-Type": "application/json",
        "Authorization": "Bearer YOUR_API_KEY",
    },
    json={
        "query": """
        {
          verifyConnection {
            authenticated
            user { id username email }
            channel { id name }
            subscription { plan state }
            permissions
            youtubeConnected
            serverVersion
          }
        }
        """
    },
)
response.raise_for_status()
result = response.json()
if result.get("errors"):
    raise RuntimeError(result["errors"])
print(result["data"]["verifyConnection"])

The exact values belong to your account, but the response has this shape:

{
  "data": {
    "verifyConnection": {
      "authenticated": true,
      "user": {
        "id": "did:rad.live:user/abc123",
        "username": "mychannel",
        "email": "me@example.com"
      },
      "subscription": {
        "plan": "Premium",
        "state": "ACTIVE"
      },
      "channel": {
        "id": "did:rad.live:channel/xyz789",
        "name": "My Channel"
      },
      "permissions": ["content:read", "content:create"],
      "youtubeConnected": false,
      "serverVersion": "2.0.0"
    }
  }
}

MCP clients should call the equivalent verify_connection tool.

Expected result: data.verifyConnection.authenticated is true, user.username identifies the intended account, and channel.id identifies the channel your writes will affect. If it does not: An authentication-policy error means the credential is missing, invalid, expired, or replaced. A null channel means the connected account has no usable channel. Start with authentication troubleshooting and the API error reference.

5. Make a useful read

Now read the first five features from the verified channel. This confirms that authentication, channel selection, and catalog access work together.

curl -X POST https://api.rad.live/graphql \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -d '{
    "query": "{ me { channel { id metadata { name } features(first: 5) { totalCount edges { node { id metadata { title } } } } } } }"
  }'

Expected result: data.me.channel.features contains totalCount and an edges array. An empty array is a valid result for a new channel.

If it does not: Confirm the channel from step 4, inspect any GraphQL errors, and use the linked documentation URL when one is present. See Pagination before requesting more than one page.

6. Choose your next useful action

Expected result: You continue with a workflow that matches your product rather than granting broader access than it needs.

If it does not: Return to the read-only query above. A successful read isolates later failures to the selected workflow instead of authentication or account selection.

7. Recover, switch, or disconnect

  • Lost or exposed API key: Select Regenerate in Developer Settings, update every connected application with the replacement, and repeat step 4. Regeneration invalidates the previous key immediately.
  • Expired OAuth access token: Use the refresh token once and store the rotated refresh token returned by the server. If refresh fails, restart authorization.
  • Wrong OAuth account: Revoke the current token with POST /oauth/revoke, sign out of Rad TV, sign in as the intended account, and authorize again.
  • Disconnect an MCP client: Call logout, then remove the Rad TV server from the client's configuration. API-key connections must be regenerated in Developer Settings if the key itself needs to be invalidated.
  • YouTube account mismatch: Reconnect the intended channel from YouTube Creator Studio. Direct API-key integrations can first call POST /youtube/disconnect.

After any recovery action, repeat step 4. Identity verification is the completion check, not merely receiving a new token.

Measuring onboarding

An integration or portal should record these events without including credentials, email addresses, or raw account identifiers:

  • api_onboarding_started when the canonical quickstart opens. Record the entry source.
  • api_auth_method_selected when the user selects an API key or OAuth. Record the authentication method.
  • api_credential_connected when key generation or OAuth approval completes. Record the authentication method.
  • api_connection_verified when me or verify_connection returns the intended account and channel. Record the authentication method, whether the account has a channel, and its plan class.
  • api_first_action_succeeded when the first useful read or write succeeds. Record the action and interface.
  • api_onboarding_recovery_started when the user follows a recovery or reconnection path. Record the failure stage and error code.
  • api_onboarding_completed when connection verification and the first useful action have both succeeded. Record the authentication method, action, and elapsed milliseconds.

Measure time to first success from api_onboarding_started to api_first_action_succeeded. Measure completion separately so an authenticated user with no channel or no successful action is not counted as onboarded.

Reference