Every release of the Velora API, newest first, written for the person who has to decide whether to change their code. Entries say what moved, whether anything you already shipped stops working, and where a previous entry on this page was wrong.
Versions are MAJOR.MINOR.PATCH. Read the Majorentries even if you skip the rest — those are the ones that can require work on your side.
v1.7.0Minor
Run polls, predictions, giveaways, goals and timers from your app
What's New
Bots and tools can now control everything a streamer runs from chat or the dashboard. New endpoints under /api/integrations/oauth: polls (active, start, end), predictions (active, start, lock, resolve, cancel), giveaways (active, start, draw, end), goals (list, adjust, change target, reset) and timers/subathons (list, start, pause, resume, end, reset, add time). See the API reference.
New scope channel:interactive:write for the control endpoints. It is reviewed before it is granted, because resolving a prediction moves viewers' channel points. Reading status uses the existing channel:read scope, so apps that already have it need no new consent to read.
Every endpoint acts on the token owner's own channel only. A token for someone who moderates other channels cannot touch those channels through the API.
Mix It Up, the Streamer.bot plugin and TrackBot already have channel:interactive:write. Streamers already connected to those three apps do not need to reconnect: the scope is added to their connection at the next token refresh (within an hour), and it appears under Connected apps in their settings. Like every scope, it only acts on their own channel.
Changes made through the API go through the same code as the dashboard: the same validation, the same overlays and chat cards, and the same events.
New events: channel.prediction.begin, channel.prediction.lock, channel.prediction.end, channel.goal.progress, channel.goal.completed and channel.timer.update. channel.goal.completed fires once per period, when the target is first reached. channel.timer.update fires on changes, not while the timer counts down. Bets, votes and giveaway entries are not events.
Poll, giveaway, prediction, goal and timer events are now delivered to webhooks too. Until now channel.poll.* and channel.giveaway.* reached the Events API only, and a webhook subscribed to them could not be created.
Fixed: channel.goal.progress and channel.goal.completed were listed in the event catalog before anything emitted them. They fire now.
Rate limits on developer write endpoints are now counted per access token (per app and streamer), not per IP address: 60 requests/minute for the new endpoints, and the 30 requests/minute documented for channel-roles, which had not been enforced.
v1.6.0Minor
Stream tags and content warnings in the API
What's New
PUT /api/integrations/oauth/stream/info now saves tags. The field was documented and accepted but never saved: a request carrying tags returned success and changed nothing. If your app has been sending tags, they will now take effect.
New field channelTags on PUT /stream/info sets the channel's identity tags (who the channel is, shown on the profile), alongside tags for the current stream.
Tags follow the same rules as the dashboard: up to 7 stream tags and 5 channel tags, and content warning tags (flashing lights, intense motion, loud or sudden audio, 18+, graphic violence, horror and jump scares, strong language, gambling, alcohol or substance use, sensitive topics) never count toward either limit. Input is stored as a slug, so "Speed Run" becomes speed-run. A list over the limit is refused with a 400 rather than trimmed, and nothing in that request is saved. The response now returns the stored title, category and tags.
GET /stream/info now returns tags, channelTags and contentWarnings (the warning tags from both lists).
New endpoint GET /api/integrations/oauth/stream/tags lists the curated tag vocabulary, which tier each tag fits (session, identity or both), whether it is a content warning, and the limits. Custom tags are allowed; the vocabulary is common ground, not a whitelist.
The stream.update event (webhooks, Events API and the event socket) now carries tags and contentWarnings, and fires when tags change during a live stream.
No new scopes and no re-authorization. Reading tags uses stream:read and writing them uses stream:write, whose consent text has always listed tags. Every app that already holds those scopes can use them today.
Fixed: a title or category change from an application erased the channel's saved default description and reset its stream languages to a single default. Fields you leave out of a request are now left as they are.
v1.5.0Minor
Honest scopes, honest endpoints, honest limits
What's New
Six OAuth scopes were being demanded by endpoints but did not exist in the registry — user:profile:read, streams:read, streams:key:read, streams:write, streams:telemetry and bot:read. The guard checks scope strings literally, so any endpoint requiring one of them returned 403 to every application no matter what it had been granted. They are now aliased to their real names (the registry uses singular stream:*), so those endpoints work and tokens already issued with the old strings keep working. A test now fails the build if a scope is ever demanded that cannot be granted.
The OAuth consent screen now shows each application's own logo and whether Velora has reviewed it. It previously described scopes from a hardcoded list of 11 while the API issues 22 — so 16 scopes, including every one of the five we consider sensitive, rendered a generic sentence that explained nothing. Descriptions now come from the live registry, permissions are grouped by category, and sensitive scopes are marked.
New page: What your app can call. Velora publishes 711 endpoints but only 48 accept a third-party OAuth token; the rest are first-party surfaces that will refuse your token whatever scopes it holds. The list is generated from the API at build time, so it cannot drift from what the server enforces.
New guide: Which API should I use? — REST, the Events API, webhooks and the chat socket compared by use case, including the delivery caveat that was documented nowhere: a webhook is delivered ONCE and never retried. If missing an event would owe a user something, reconcile against REST rather than trusting delivery.
SRT has been removed from every ingest payload. It was withdrawn in May and is disabled fleet-wide, but the API was still returning an srt:// URL to streaming applications — any integration that used it would fail to publish silently. WHIP is now returned first, with an explicit preferredProtocol field, because WHIP/WebRTC is the recommended path for application integrations.
Corrections to the reference: the Getting Started example called an endpoint that does not exist, key regeneration was documented as GET when it is POST, four other documented paths returned 404, and the chat guide's curl was missing a path segment. A build-time check now compares every documented endpoint against the live API specification.
The Rate Limits page has been corrected. The previous entry in this changelog said it had been rewritten to match what is actually enforced; that was not accurate. What is enforced today is a global limit of 600 requests per minute per IP, and 120 per minute on subscription endpoints. The per-category figures are budgets we intend to enforce per application and do not yet. The page now says which is which, because designing a retry strategy around a limit we do not apply is worse than knowing there is only a global one.
v1.4.0Minor
Grant VIP via the API + Documented Rate Limits
What's New
Added the channel:roles:write scope — your app can now grant and remove VIP and moderator on the authorizing user's own channel. This lets a channel-point reward hand out VIP through the API instead of it being dashboard-only. Requested by a partner building exactly that.
Added POST /api/integrations/oauth/channel-roles to grant a role (VIP or moderator) by memberId or username, with an optional expiresAt; and DELETE /api/integrations/oauth/channel-roles/:memberId/:roleType to remove one. Both are scoped to the authorizing user's own channel and rate-limited to 30 requests/minute. GET /api/integrations/oauth/channel-roles lists the current roles (channel:read).
channel:roles:write is a sensitive scope: it requires a verified email, a written justification, and a human staff review before it is granted — never auto-approved, partners included. Assigning who holds elevated standing in someone's channel is exactly the kind of access that gets read by a person first.
Grants reuse the same role logic as the dashboard and the in-chat /vip command, so badges appear on the member's open chat sockets immediately, and expiry behaves identically across every path. broadcaster is not grantable through the API.
The Rate Limits documentation page has been rewritten to match what is actually enforced: a per-category table (chat, channel roles, subscriptions, events, bots, OAuth, app management), the honest Sandbox / Production / Partner tiers, and how to arrange a custom per-application limit. It replaces earlier values that did not reflect the live configuration.
v1.3.0Minor
Interaction Events Now Fire + Honest Event Catalog
What's New
channel.poll.begin and channel.poll.end now actually fire. Polls have always worked on Velora, but they only broadcast internally — the Events API never saw them, so a subscription to either event stayed silently empty. Both now emit on the real poll lifecycle: begin when a poll is created, end when it closes or is cancelled.
Added channel.giveaway.begin and channel.giveaway.end — a working feature that was never exposed on the Events API at all. begin fires when a giveaway opens for entries; end fires when it closes or is cancelled.
Poll and giveaway events fire on lifecycle transitions only, not on every vote or entry. Per-vote and per-entry noise would flood your subscription; read the poll or giveaway resource directly if you need live tallies.
REMOVED channel.prediction.begin, channel.prediction.lock, channel.prediction.end, channel.hype_train.begin, channel.hype_train.progress, and channel.hype_train.end. Velora has no Predictions or Hype Train feature, and these six events had never fired since the platform launched. They were listed in error. If you subscribed to any of them, you were receiving nothing — no code change is needed on your side, and you can safely delete those handlers. If we ever build these features, the events will return alongside them.
GET /api/events/types now lists only events that a real Velora feature emits. If it is in the catalog, something on the platform fires it.
Documentation: the Interaction Events table on the Events API page now matches the live catalog exactly.
v1.2.1Patch
developer.velora.tv Is Now the Canonical Portal
What's New
Every developer page now lives at developer.velora.tv. The old velora.tv/developer/* URLs, and the duplicate developer.velora.tv/developer/* form, both permanently redirect (308) to the canonical address. Existing bookmarks and links keep working — they just land on the canonical URL.
308 was chosen over 302 deliberately: it is permanent AND preserves the HTTP method, so a POST that hits a redirect will not silently become a GET.
New: Bots & Sub-Accounts guide at developer.velora.tv/docs/bots — how a bot is registered as a sub-account of a creator's channel (not a second, separate account), how it is named and given an avatar, how commands sync to the channel Commands page, and what a bot can actually do.
Documented the real bot moderation model: a bot needs the chat:moderate scope AND the moderator role in that specific channel, granted by the creator, exactly like a human moderator. A scope alone is not enough.
Documented the command permission ladder as it is actually enforced: everyone, followers (with optional minimum follow age), subscribers, tier1/tier2/tier3 (that tier or above), vips (VIPs and moderators), moderators, and streamer_only. An unrecognized level denies by default.
v1.2.0Minor
Subscriber API + subscription.end Webhook
What's New
Added GET /api/developer/subscriptions/count — the authoritative, offline-safe count of your channel's active (non-expired) subscribers. Does not depend on who is currently online.
Added GET /api/developer/subscriptions — a paginated roster of your active subscribers, each with userId, username, displayName, tier, isGift + gifter, and expiresAt, alongside the authoritative full-channel total (independent of the page window). Query params: page (1-based, default 1) and perPage (1–100, default 50).
Both endpoints require the subscriptions:read scope (broadcaster-approved) and are scoped to the authorizing user's own channel only. Output is PII-safe (id/username/displayName/tier/gift/expiry only).
Added new webhook event channel.subscription.end — fires the instant a subscription ends, whether canceled or naturally expired (including gift subs, which never auto-renew), so you can keep your subscriber count accurate in real time. Payload carries userId, username, displayName, tier, isGift + gifter, reason (canceled | expired), endedAt, and expiresAt.
Added userId to the channel.subscribe and channel.subscription.gift webhook payloads so you can match a subscribe event to its later subscription.end by the immutable user id (usernames can be renamed).
Rate limit: the subscriber endpoints allow 120 requests/minute per client; exceeding it returns 429 Too Many Requests.
v1.1.0Minor
Chat Mentions, User Badges & Card Messages in SSE
What's New
chat.message events now include a mentions array with resolved @mention user data (userId, username, displayName)
New GET /api/badges/user/:username endpoint — get a user's badges in any channel (public, no auth required)
Card messages (stickers, sounds, celebrations) now emit on the chat.message SSE stream with a card object
subscriberMonths now populated in chat.message events (previously was always undefined)
Username lookups are now case-insensitive across badge and mention resolution
v1.0.0Major
Developer Platform Launch
What's New
Initial release of the Velora Developer Platform
OAuth 2.0 authentication with PKCE support
RESTful API for streams, users, chat, and subscriptions
Real-time webhooks for stream events
Developer Dashboard for app management
Comprehensive API documentation
You've reached the beginning — v1.0.0 is the first public release of the Velora Developer Platform.