Channel allowlist

Slipstream’s catalog is registered with the Content-ID systems the video platforms use. That is what protects the music — and it means a creator who publishes a video with a Slipstream track can see an automated claim on it, even though they are entitled to the track.

Registering a creator’s channel on the allowlist stops those claims at the source: the channel is cleared for our catalog, so videos published on it are not claimed in the first place.

Use this when your product manages channels on a creator’s behalf. If instead you need proof to resolve a claim that has already been filed, see Licensing.

Endpoints

Authentication

Authorization: Bearer <PARTNER_API_KEY>

The same key as the other partner endpoints. Channel management is granted per partner and is off until it is enabled: without it every endpoint here returns 403, naming the channel_manage grant it is missing. Contact your Slipstream representative to have it enabled.

YouTube only

Content-ID registration applies to YouTube channels, so YouTube is the only platform you can add. Channels on other platforms that are already on the account remain readable and removable here.

value is the YouTube channel id — the 24-character string beginning with UC, not a handle, a custom URL, or a full page URL. You can read it from the YouTube Data API, or from the channel’s page source.

Acting for your end users

If you manage channels for many creators, send an X-User-ID header naming which one a call is for. Their channels are then kept separate from each other and from your own:

X-User-ID: creator-4821

The id is yours to choose — whatever you already call that creator, as long as it stays the same for them. Adding a creator’s first channel is what registers them with us, so there is no roster to send in advance. Reading an id we have not seen yet answers 404: there is nothing under it until you add something. Omit the header to work with the channels registered to your own account.

One channel, one allowlist

A YouTube channel can be registered once across Slipstream. If it is already registered — by you, by one of your end users, or by another account — the request is refused with 400. The message distinguishes the two cases, because they call for different handling:

Concurrent adds for the same channel are serialised: one of them succeeds with 201 and the rest answer 400 with This channel is already on your allowlist. You will not end up with two entries.

Removing a channel

DELETE removes the channel from your allowlist straight away: it stops appearing in List and Retrieve answers 404.

Removal is reversible. Adding the same channel again restores the original entry, with the same id it had before.

Pagination

A limit above the maximum is clamped, not refused. Responses use the standard paginated envelope:

{
  "count": 128,
  "next": "https://api.slipstreammusic.com/api/v4/allowlist/channels/?limit=50&offset=50",
  "previous": null,
  "results": []
}

count is the total number of channels, not the size of the page. next and previous are absolute URLs, and null when there is no page in that direction. Channels come back newest first.

The channel object

{
  "id": "9b5c3d2e-0a8e-4b7c-8c4d-2f9e5f6b8d7c",
  "channel_id": "UC_x5XG1OV2P6uZZ5FSM9Ttw",
  "name": "Google for Developers",
  "provider": "youtube",
  "image_url": "https://yt3.ggpht.com/..."
}

Rate limits

Up to 60 requests per minute, counted against your partner account as a whole — one shared budget across every key you hold and every end user you act for, not 60 each. On top of that sits a usage allowance on channel management agreed with your Slipstream representative. Exceeding either returns 429; the response body says when it resets.

The allowance covers every call on these endpoints, removals included. Requests rejected with a 4xx are refunded, so a retry after a validation error does not cost you twice. If you expect to manage a large roster, ask for the allowance to be raised before you start rather than after.

Errors

Error body

These endpoints answer in the shape the rest of /api/v4 uses, which is not the one shown on the API reference overview for /api/v1.

A rejected POST returns the reasons keyed by what they apply to — non_field_errors for anything about the channel as a whole:

{
  "non_field_errors": ["This channel is already on your allowlist."]
}

{
  "provider": ["\"vimeo\" is not a valid choice."]
}

Everything else — 401, 403, 404, 406, 429 — answers with a single detail string:

{
  "detail": "Unknown external user id."
}

Branch on the HTTP status, not on the message: the strings are English prose meant for a human reading a log, and they can change.