VTube Studio has a public API, and the legal terms are unusually clear

A public API for a Live2D avatar app, documented on a wiki

VTube Studio is a Live2D avatar application, and this repository is its API development page. The structure of the documentation tells you it is a reference, not a library you install.

The general information section states the core fact plainly: VTube Studio has a public API, and you are able to write plugins and scripts that can trigger hotkeys, feed in face tracking data, load items, load models, get event notifications for various events, tint model ArtMeshes and much more.

The page is organised as a table of contents that runs to several dozen entries, and the shape of that list is the clearest description of the API's scope. There are operations to get the current statistics, to list the VTS folders, to get the currently loaded model, to list available models and to load a model by its ID, to move the loaded model, to list hotkeys in the current or another model and to request their execution, to list expressions and their states and to activate or deactivate them.

Then the deeper control: listing ArtMeshes in the current model or at a position, tinting ArtMeshes with a colour, reading the scene lighting overlay colour, checking whether the face is currently found by the tracker, reading and setting tracking parameters including custom ones, feeding data into those parameters, reading and overriding the physics settings of the loaded model, and getting or setting the NDI settings.

The scene and effects round it out, with operations to list and load items, remove them, control items and their animations, move them, set within-model sorting, ask the user to select ArtMeshes, pin items to the model, and read and set post-processing effects.

For a reader, that list is the actual API surface. Everything in it is something the application can be asked to do at runtime, which is a much larger surface than a screen capture or a tracking bridge.

Permissions and authentication come before anything else

Two sections sit at the front of the API details, and they are the ones to read first: API permissions and authentication.

The permissions model is the reason a VTube Studio plugin can do things like load a model or move it around the screen without being a security risk. A plugin is not trusted by default. It is granted a set of permissions, and the user can see and change that set from inside the application, which is what makes a public API for an application that renders a user's avatar workable at all.

Authentication is the second gate. The documentation has a section for it alongside the permissions section, and a separate section for API server discovery over UDP, which is how a client finds the application on the machine before it connects.

The order of these sections in the reference reflects the order a developer hits them. You do not get to the interesting operations until you know how the client locates the running application and how the user grants it the rights to do the things you want.

That is also why permissions are worth reading as a design constraint rather than a chore. If your plugin needs to move the model and tint ArtMeshes and load items, the permission prompt the user sees is a list of those capabilities, and a plugin that asks for more than it uses produces a prompt that looks alarming. Knowing the permission names in advance is how you design around that.

The API is a WebSocket, and events are the way to watch it

The protocol itself is not described in the table of contents as a separate top level entry, but the shape of the reference makes it clear. The event API has its own section, and the operation list is organised as request and response pairs, with a section on subscribing to and unsubscribing from events and then a long run of specific queries that each return current state.

That is the shape of a request and response protocol over a persistent connection rather than a set of REST endpoints, and the mechanism fits the problem. A Live2D avatar application is a live state machine that a user is watching in real time, and the plugin wants to react to that state rather than poll for it. Events give it the push side.

The sections for subscribing and unsubscribing are what make the event model usable. An app that only wants to know when the model changes subscribes to that one event, and an app that wants every parameter update subscribes broadly. Unsubscribing matters for the same reason, since an event stream that is never closed keeps work alive after the plugin has nothing to do with it.

The statistics section, and the separate sections for the current model, the available models, the current expression state list and the parameter values, are the read side. Between the event stream and the query catalogue, a plugin has both a way to be told what changed and a way to ask what is true right now, which is the combination a well behaved integration needs.

The operation catalogue in four groups, and why the grouping matters

The several dozen operations in the reference are easier to reason about in four groups.

The identity group is about what is loaded: statistics, folders, the current model, the list of available models, loading a model by ID and moving it. These are the operations that change which avatar is on screen and where it sits.

The control group is about expression and animation: listing hotkeys in the current or another model, executing a hotkey, listing expressions and their states, and activating or deactivating them. A hotkey in this application is a named action the user has bound, so executing one is a way to trigger behaviour the user configured rather than inventing a new one.

The parameter group is the largest and the most interesting for a plugin. It covers ArtMesh listing, tinting ArtMeshes with a colour, the scene lighting overlay colour, whether the face is currently found by the tracker, the available tracking parameters, reading one specific parameter with a default or custom value, reading all Live2D parameters in the current model, adding and deleting custom parameters, and feeding data into those parameters.

The scene group covers the things around the model: NDI settings, listing and loading items, removing items, controlling items and item animations, moving them, within-model sorting, asking the user to select ArtMeshes, pinning items to the model, and post-processing effects.

The grouping matters for a different reason than navigation. The parameter group is the part that can feed data into the avatar, and it is the part with the most subtle failure modes, because a plugin that writes a tracking parameter every frame is responsible for the value it writes. A plugin that only reads statistics has no such responsibility.

The legal section: no permission, no fees, no royalties

The legal info section is short and unusually direct, and for anyone hesitating about building a commercial tool it is the most consequential part of the page.

You are free to write, publish and sell any plugin you want for VTube Studio. No permission is required and there are no licensing fees or royalties.

That is a stronger grant than most application plugin ecosystems offer, where a commercial extension needs a licence agreement, a revenue share or an app review. Here there is no gatekeeper, which cuts both ways. There is no fee and no delay, and there is also no approval process, so nothing checks a plugin's behaviour before it runs.

The mechanism for listing is a pull request. If you develop a plugin or an app that can be used with VTube Studio, the instruction is to open a pull request and it will be added to the list on the page. The examples table carries the same note in stronger form, asking developers to open a pull request with a modified table if they have something to add.

So the directory is community maintained and self declared. A listing tells you a developer says their project works with the application, and nothing more.

The distinction between the two audiences is handled early in the page as well. Users looking for plugins are sent to a wiki page listing them, while developers are told that everything they are looking for is on the page itself, and that questions can be asked in the Discord.

Examples: a Twitch bot, a JavaScript library, and an emulated console

The examples section gathers projects built against the API, and the table format makes the point that these are external projects rather than official components. Each entry names the plugin, the developer, the type and an explanation.

Cheers Bot is listed as an app, a web-based Twitch integration platform which can trigger actions in VTube Studio when chatters redeem channel points, among many other features. That is the clearest example of the API's commercial shape: a service for streamers that monetises chat activity by driving the avatar.

VTubeStudioJS is listed as a library, a JavaScript library for use by other plugin authors which implements the VTube Studio WebSocket API, and it is compatible with both NodeJS and the browser. This is the entry most developers should look at first, because it means the protocol work is already done. The compatibility note matters: the same code running in a browser and in Node means a plugin can be a web page, a service, or both, without reimplementing the connection.

The third entry, VTS Linker - SMB1, is listed as an example and described as a prototype for reading data from an emulated copy of Super Mario Bros, and using that data to automatically move and recolor a Live2D model in VTS. It is a proof that the API can be driven by something that has nothing to do with streaming, which is the point of an example in a table like this.

All three are third-party work, and the type column is what tells you what you are looking at: an app you run, a library you import, or a prototype you read.

Where the documentation lives, and the one workflow that points elsewhere

The repository itself is small. The top level holds a README, a LICENSE, and four directories, Events/, Files/, Images/ and Permissions/, alongside a .gitignore. The documentation is the README plus the wiki, and the wiki is where the manual and the plugin list live.

That arrangement makes sense for a documentation repository. The wiki is editable by the community, the plugin list changes often, and the API reference is a long structured document that a wiki handles better than a repository of markdown files.

There is one exception that the page is explicit about. If you are a developer looking for a way to receive tracking data from the VTube Studio iPhone app, this repository is not where that process is described. It points at a separate repository, the VTubeStudioBlendshapeUDPReceiverTest, and says the process for requesting tracking data from the iOS app is described there.

That distinction is easy to miss and expensive to miss. The iPhone app is a different client of the same application, and a plugin that wants to receive tracking from the phone rather than from a webcam or a face tracker follows a different request process, with its own repository to read.

The project is MIT licensed, the primary language is listed as C#, and the last push was on 2026-09-28 with no GitHub releases. That is normal for a documentation repository: the release history of an API is the history of the application, not of this page, and the wiki carries the day to day changes.

Editorial conclusion

Adopt this API if you are building a stream tool, a chat bot or a hardware bridge for VTube Studio and need to drive the avatar rather than only watch it. Do not adopt it if you only need to read tracking data from the iPhone app, because the project points that workflow at a separate receiver test repository instead. Before you write a client, read the permissions and authentication sections first, because a plugin is granted an explicit permission set at pairing time and the operations you can call depend on it, and pick a language binding that already implements the WebSocket protocol if you can, since the event and request identifiers are the part you will otherwise get wrong.

Frequently asked questions

Official sources

1. DenchiSoft/VTubeStudio on GitHub
2. Issues
3. License: MIT
4. README