Documentation
A topic-by-topic reference for the complete plugin development workflow.
Use this section to look up exact concepts, fields, APIs and behaviors. If you want a working first project, start with Get started and return here when a topic becomes relevant.
Understand the system
- How plugins work: phone, helper, executable, catalog and invocation.
- Project structure: source files, development configuration, SDK dependencies and release artifacts.
- Manifest reference: every supported manifest field and compatibility declarations.
- Buttons and actions: IDs, titles, payloads and editor behavior.
Implement the behavior
- SDK reference: required/optional interfaces and host methods in all four languages.
- Protocol reference: JSON lines, correlation, request/reply shapes, lifecycle and errors.
- Core capabilities: typed clients, permissions and subscriptions.
- Media, keyboard, pointer, applications: complete method/topic/type references generated from the public schemas.
- Providers and dependencies: exposing reusable capabilities and consuming another plugin.
- Configuration: packaged defaults, user settings and secrets.
Ship and maintain it
- Packaging and distribution: runtime resources, platform builds, notices and installation.
- Versions and upgrades: API vs plugin vs capability versions and compatibility ranges.
- Testing: deterministic logic checks, packaged checks and real-device scenarios.
- Troubleshooting: startup, framing, missing dependencies and unavailable features.
- Contributing: where source/docs changes go and how the website adopts them.
Terms used throughout the guide
| Term | Meaning |
|---|---|
| SDK | Public libraries and tools used by your plugin |
| Plugin | Your executable implementation and its declared actions |
| Helper / host | AirDeck's computer-side application that starts plugins and routes commands |
| Catalog | The list of actions/buttons your plugin offers |
| Invocation | One request to perform a particular action |
| Capability | A versioned service exposed by the helper or a provider plugin |
| Permission | A grant required to use a broker operation or topic |
| Package | A .deckPlugin archive containing installation/runtime files |
This reference covers API v2. A successful protocol response means the handler completed successfully; it is not a guarantee that every external application supports the requested operation.
Edit this page on GitHub ↗Community-maintained · API v2