Vera API Documentation: Complete Developer Guide

ByMelisa Fumero

The Vera API provides developers and advanced users with direct access to Vera controllers through a collection of HTTP-based endpoints. These interfaces make it possible to monitor devices, trigger scenes, modify variables, and build custom integrations without relying solely on the graphical user interface.

Whether you’re developing a mobile application, integrating a third-party platform, or automating complex smart home workflows, the Vera API offers a flexible way to interact with your controller programmatically.

This guide explains the API architecture, authentication methods, common endpoints, request formats, and practical examples to help you get started.

What Is the Vera API?

The Vera API is a collection of HTTP endpoints exposed by the controller that allow applications and scripts to communicate directly with the automation engine.

Using these endpoints, you can:

  • Read device information
  • Control switches
  • Lock and unlock doors
  • Trigger scenes
  • Read sensors
  • Modify variables
  • Query system status
  • Execute Luup code
  • Build custom dashboards

Most API requests return data in JSON format, making integration straightforward for many programming languages.

How the Vera API Works

Every API request follows a similar process.

Application

↓

HTTP Request

↓

Vera Controller

↓

Luup Engine

↓

Device

↓

JSON Response

Example:

Your application sends a request to turn on a smart switch.

The Vera controller validates the request, forwards it to the Luup engine, communicates with the device, and returns a response confirming the result.

Local vs Remote API Access

Local API

The local API communicates directly with the controller over your home network.

Example: http://192.168.1.xxx:3480/

Advantages:

  • Faster response
  • No internet dependency
  • Lower latency
  • Better privacy

Most integrations use local access whenever possible.

Remote API

Remote access allows applications to communicate with the controller over the internet.

Advantages:

  • Access while away from home
  • Mobile applications
  • Cloud integrations

Considerations:

  • Depends on internet connectivity
  • May introduce additional latency
  • Follow secure authentication practices

API Architecture

The Vera platform consists of several interacting components.

Client Application

↓

HTTP API

↓

Luup Engine

↓

Device Plugins

↓

Z-Wave / Zigbee Devices

Each layer has a specific role:

Client Application

Your custom software.

Examples:

  • Mobile app
  • Dashboard
  • Home automation server
  • Voice assistant
  • Integration platform

HTTP API

Processes incoming requests.

Responsibilities:

  • Parse parameters
  • Validate commands
  • Return responses

Luup Engine

The automation engine responsible for:

  • Device control
  • Variables
  • Scenes
  • Plugins
  • Event handling

Device Plugins

Plugins translate API requests into commands understood by individual devices.

Examples:

  • Lighting
  • Locks
  • Sensors
  • Thermostats

Authentication

Authentication depends on whether you’re using local or remote access.

Local API access on trusted home networks is typically simpler, while remote access generally requires account-based authentication and secure communication.

Always:

  • Use strong passwords.
  • Protect administrator accounts.
  • Restrict unnecessary network exposure.
  • Prefer encrypted connections where available.

Request Format

Most requests follow a standard HTTP structure.

General format:

http://controller_ip:3480/data_request?id=REQUEST_NAME

Additional parameters are appended to specify the desired action or target device.

For example, a request might include:

  • Request identifier
  • Device number
  • Service identifier
  • Action name
  • Variable values

Using a consistent URL structure makes the API predictable and easy to integrate.

Response Format

Most Vera API responses are returned as JSON.

A response may include:

  • Device identifiers
  • Current status
  • Variable values
  • Success or error information
  • Timestamps

JSON is supported by virtually every modern programming language, making it ideal for custom integrations.

Common API Endpoints

The Vera API provides endpoints for a wide range of controller functions.

Common categories include:

System Information

Retrieve:

  • Controller status
  • Firmware version
  • Device count
  • System information

Device Information

Read:

  • Device names
  • Device IDs
  • Current states
  • Room assignments
  • Categories

Device Control

Execute commands such as:

  • Turn lights on/off
  • Lock or unlock doors
  • Adjust dimmer levels
  • Change thermostat settings
  • Activate switches

Scene Control

Available actions include:

  • Start scenes
  • Stop scenes
  • Query available scenes
  • Check execution status

Variable Management

Read and update:

  • Device variables
  • Plugin variables
  • User-defined values
  • Automation settings

Luup Functions

Advanced users can:

  • Execute Luup code
  • Trigger custom scripts
  • Read Lua variables
  • Build plugin integrations

HTTP Methods

Most Vera API interactions rely on standard HTTP methods.

GET

Used to retrieve information without modifying controller state.

Examples include:

  • Device status
  • Variables
  • Scene lists

POST

Used when sending data that changes the controller’s state.

Examples include:

  • Executing actions
  • Updating variables
  • Triggering automations

Understanding JSON Responses

A typical response contains structured data representing the requested resource.

Common fields include:

  • Device number
  • Device name
  • Service identifier
  • Variable value
  • Timestamp
  • Status code

Learning to parse JSON responses is essential when building applications that communicate with the Vera controller.

Similar Posts