Favourite Episodes and Clips by Type in BBC Radio & Music
A documented BBC Radio & Music operation that only reads, so it can watch for changes without altering anything. Describe what you want to happen and HumDay builds it.
What this operation does
Favourite Episodes and Clips by Type
- GETReads data · Radio
rms.api.bbc.co.uk/my/radio/favourites/{type}
How HumDay uses it
- You describe the outcome. Not this operation by name — what you want to happen. HumDay works out which operations it needs.
- The contract names it. Before anything is built, you see exactly which BBC Radio & Music operations the program may use, and this is one of them.
- You approve access. Read-only access is still yours to grant, and still limited to what the contract needs.
Other BBC Radio & Music operations
- Write Play EventPOST · changes data
- Followed Networks, Categories, Artists, Playlists and GenresPOST · changes data
- Followed Networks, Categories, Artists, Playlists and GenresPUT · changes data
- Followed Brands and SeriesPOST · changes data
- Followed Brands and SeriesPUT · changes data
- Favourite Tracks or ClipsPOST · changes data
- Favourite Tracks or ClipsPUT · changes data
- Unfollow networkDELETE · changes data
Questions
- Can HumDay favourite episodes and clips by type in BBC Radio & Music?
- Yes. This operation is published in BBC Radio & Music's own API description, so HumDay can use it without a hand-built connector — once you have approved it for your automation.
- Does this change anything in my BBC Radio & Music account?
- No. This is a read-only operation, so it can be used to watch for changes or fetch data without altering anything in BBC Radio & Music.
- Do I need to write code?
- No. You describe the outcome you want in plain words. HumDay agrees a contract with you, writes the program, and shows you a proof run before anything touches your BBC Radio & Music account.
Where this came from
Read from a published API description for BBC Radio & Music at rms.api.bbc.co.uk/docs/swagger.json. The description above is the provider’s own wording, not ours. Last published 2017-09-25.