APIs, MCP and custom applications

A digital signage API and MCP server for developers.

Everything in the Wallboard console runs on a REST API you can call too. Authenticate with OAuth 2.0, read the OpenAPI spec for the domain you need and script the jobs the console makes you repeat. When another system only needs to flip a switch, give it a webhook key that can do that one thing, and when an AI assistant or your own app needs to talk to Wallboard, the MCP server and AI endpoints use the same permissions as everyone else.

How it works

From first token to working integration.

  1. Choose an auth flow

    Use PKCE for browser apps and CLIs, a confidential client for server apps, or a service account for machine jobs.

  2. Find the endpoint

    Pick one of 18 OpenAPI specs. Or give llms.txt to your coding assistant first.

  3. Query with WBQL

    Filter and sort with Wallboard’s query syntax. Scope every call to one customer.

  4. Trigger from outside

    Create a webhook action and a scoped key. Your system posts an event ID and Wallboard runs the action.

What you can build on.

REST API

Devices, content, channels, files, datasources and users. Each domain has its own OpenAPI spec.

Webhook triggers

Set datasource values, switch emergency content, change volume, assign content, pass sensor data or clear CAP alerts.

Scoped API keys

Each key gets one scope, such as webhook calls or Proof of Play reads. Switch it off any time.

MCP server

AI assistants look up endpoints and schemas, then read or write data. Per-user AI limits apply.

AI endpoints

Text or structured JSON with sessions, tool calls and streaming. Images and speech too.

External web apps on screen

Show your own web app in a native webview, not an iframe. Script injection is optional.

When the standard types aren’t enough.

Most integrations fit an existing datasource, such as JSON, XML, JDBC or one of the named connectors, or a webhook. Some don’t. Multi-step or certificate-based sign-in, several APIs that must be combined, a legacy system or a proprietary protocol can be handled as a custom datasource. That is project work, so it starts with the external system’s documentation, sample data, a technical contact and a budget your team has approved.

Tell us what you want to connect.

Send us the system and the outcome you need. Our team will tell you whether it is an API script, a webhook, a standard datasource or a custom project, and our support engineers stay with you through the build.