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
| Method | Path | Use when |
|---|---|---|
GET | /api/v4/allowlist/channels/ | You want the channels currently on the allowlist |
POST | /api/v4/allowlist/channels/ | You want to register a channel |
GET | /api/v4/allowlist/channels/{id}/ | You want one channel back by its id |
DELETE | /api/v4/allowlist/channels/{id}/ | You want to stop protecting a channel |
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.
Platforms
You can register a channel on any platform the Slipstream app itself offers:
provider | What to send as value |
|---|---|
youtube | The 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 |
instagram | The profile URL, on instagram.com — with or without www., it is stored with |
tiktok | The profile URL |
facebook | The page or profile URL |
rss | The feed URL, stored as you send it. It has to be publicly reachable and to answer where you point it — a URL that redirects permanently is refused, so send the destination |
website | The site URL |
Adding a YouTube channel registers it for Content-ID, which is what stops claims on the videos published there.
Off YouTube the profile URL is the entry’s name and channel_id comes back null. The URL is normalised on the way in — http becomes https, and a profile URL is stored with a trailing slash.
If your creators submit videos to AudioVerify, you can skip this endpoint for them: pass their channel URL as channel_url on the submit and the channel is added to that creator’s allowlist in the same call, with the entry’s id in the response. See Naming the creator’s channel.
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-4821The 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 channel can be registered once across Slipstream — a YouTube channel by its id, a channel on any other platform by its URL. 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:
| Message | What it means | What to do |
|---|---|---|
This channel is already on your allowlist. | You already registered it, under the same end user | Nothing. It is already registered |
This channel is registered to another Slipstream account, so it can't be added. | Someone else holds it, possibly another of your end users | The creator needs to remove it there first |
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
| Parameter | Default | Max | Description |
|---|---|---|---|
limit | 50 | 200 | Number of channels per page |
offset | 0 | — | Index to start from |
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/..."
}| Field | Description |
|---|---|
id | Slipstream’s identifier for this allowlist entry. Use it to retrieve or remove the channel. |
channel_id | The platform’s own id — for YouTube, the UC… string you sent as value. Keep it: it is how you match a channel back to your own records, and how you find an entry again if you lose the id. null on every other platform, where the profile URL is the identity and comes back as name. |
name | Channel name as the platform reports it. Creators can change it, so do not key on it. |
provider | Lowercase platform key — one of the values in Platforms, spelled exactly as you send it. A channel added inside the Slipstream app can carry a key that is not on that list. |
image_url | Channel avatar, or null if the platform gave us none. |
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
| HTTP | When |
|---|---|
| 400 | The channel could not be added — it could not be verified (an id that resolves to no YouTube channel, an Instagram URL on another host, a feed that is not publicly reachable), it is already registered, or your plan’s channel allowance is used up. That last one applies to channels on your own account; channels added under X-User-ID are not counted against it. The body says which |
| 401 | No credential, or the credential is not recognised |
| 403 | The credential has been deactivated, revoked or has expired; channel management is not enabled on your account; or X-User-ID was sent from an account without end-user support |
| 404 | No such channel on this allowlist, or a read named an end user we have no record of |
| 406 | These endpoints only produce JSON. Send Accept: application/json or */* |
| 429 | Rate limit or usage allowance exceeded. The body says when it resets — back off until then rather than retrying |
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."]
}…and value for anything about the value you sent:
{
"value": ["A feed URL has to be reachable on the public internet."]
}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.