Introduction:
The API as the Engine of Value
In any advanced technology platform, the Application Programming Interface (API) is the critical conduit through which raw capability is transformed into tangible results. For a Real-Time Locating System (RTLS) such as the Quuppa Positioning Engine (QPE), the API is even more fundamental: it determines whether the system delivers a “firehose” of raw data or a refined stream of operational truth. A seductive dot moving on a map is not the end goal; the true objective is a trustworthy digital representation of physical operations—what we call the Reality Layer.
This white paper provides an in-depth analysis of the QPE API’s evolution through its major releases, tracing its development from a provider of location coordinates to a sophisticated, event-driven integration framework. This journey reveals more than technical enhancements; it reflects the platform’s strategic maturation, designed to empower developers and system integrators.
The core thesis of this paper is that the API’s evolution is the story of Quuppa building the tools necessary to create this trustworthy Reality Layer. By systematically adding layers of control—over data format, delivery cadence, filtering, and transformation—Quuppa has shifted the integration paradigm from consuming raw signals to defining operational truth directly at the source. This paper will examine the key eras of this evolution, beginning with the foundational architectural shift introduced in version 7.0.
A Foundational Shift:
The Birth of the Modern Data API in QPE 7.0
The release of QPE version 7.0.0 in February 2021 marked a watershed moment for the platform’s data integration capabilities. This version introduced a fundamental paradigm shift, moving away from a set of rigid, predefined data endpoints toward a flexible, developer-defined data access model. It was the first major step in empowering integrators to request the exact data they needed, in the format they required.
Strategically, the most significant change was the deprecation of the legacy getTagPosition and getTagInformation API commands. This move signalled the end of a “one-size-fits-all” approach to data retrieval, where developers were forced to make separate calls for different types of tag data and handle the outputs as-is.
In their place, Quuppa introduced the unified getTagData API command. The power of this new command came from its accompanying markup language, which for the first time allowed developers to define the precise structure and content of the API response. Whether the downstream application required a lean set of coordinates in CSV format or a rich JSON object with detailed tag information, getTagData could be configured to provide it in a single, efficient call.
This new data access model was complemented by a new suite of API commands for managing persistent data streams: listOutputTargets, createOutputTarget, and controlOutputTarget. Collectively, these commands provided the foundational tools for creating, managing, and controlling purpose-built data streams directly from the QPE, laying the groundwork for more advanced event-driven architectures.
The contrast between the old and new models highlights the significance of this release.
| Pre-7.0 API Model | Post-7.0 API Model |
Separate, rigid commands for position (getTagPosition) and info (getTagInfo). | A single, unified getTagData command for all tag-related data. |
| Fixed, predefined response formats for each command. | Fully configurable response format using a markup language, supporting both JSON and CSV. |
| Lacked native, API-driven tools for managing persistent data streams. | A comprehensive suite of commands for creating and controlling Output Targets, with support for persistent configurations. |
| Architectural Burden: Data fusion and schema mapping handled in client application or middleware, increasing code complexity. | Architectural Benefit: Data fusion and formatting are handled at the source by the QPE, simplifying integration logic and reducing network overhead. |
This new foundation of a unified data command and programmatic stream management set the stage for subsequent enhancements that would provide even more granular control over the data flow.
Refining the Flow:
Batching, Triggers, and Protocol Expansion (Versions 7.x – 9.3)
Following the major architectural changes in version 7.0, subsequent releases focused on refining the data delivery mechanisms. This phase of the API’s evolution can be characterised as a concerted effort to “tame the firehose,” giving integrators powerful new tools to manage data volume, cadence, and transport protocols. It marked the moment the API realised a crucial insight: Events are reality, not coordinates.
This period saw a critical evolution in data triggering mechanisms. Version 9.3.1 (June 23rd 2025) refactored the trigger modes for output targets and, most importantly, introduced the onDataChange parameter. This addition was pivotal, enabling true event-driven workflows. Instead of sending data at a fixed interval, developers can configure the QPE to send an update only when a specific, meaningful change occurs. This is where the QPE began to speak the language of business operations (an asset entered a zone, a button was pressed) rather than just the language of physics (its coordinates are X, Y, Z). This prevents redundant data transmission and ensures that downstream systems respond only to new information.
A key enhancement for managing data volume was introduced with message batching in version 9.3.1. The maxBatchSize parameter allowed developers to configure an output target to collect multiple tag events into a single message before sending it. The impact of this feature is significant for large-scale systems, as it directly reduces network traffic, minimises the frequency of database writes, and lowers the overall processing load on receiving applications.
The platform’s integration capabilities were further broadened with the introduction of the MQTT Publisher in version 8.5.2 (September 2023). By adding native MQTT support, a lightweight, ubiquitous IoT messaging protocol, Quuppa dramatically simplified integration. For an architect, this is a critical distinction: it enables the QPE to become a first-class citizen in modern IoT architectures, publishing events directly to enterprise message brokers or cloud IoT platforms, such as AWS IoT Core or Azure IoT Hub, without requiring an intermediate polling service or a custom protocol bridge.
In summary, this evolutionary phase marked the maturation of the QPE API from a flexible data source into an intelligent data gateway, paving the way for the next level of in-engine data manipulation.
The Apex of Control:
In-Engine Filtering and Transformation in QPE 9.5
The release of QPE 9.5.1 on December 19th 2025, represents a significant step in the platform’s move toward source-side data control, significantly advancing the philosophy of designing relevance at the source. While previous versions allowed developers to manage data timing and batching, this release added a new level of granularity: the ability to precisely filter and reshape data before it leaves the engine.
The introduction of the 'filter by' parameter for output targets had a profound impact on integration architecture. This feature allows predefined filtering criteria—such as zone change events, location updates, or button presses—to be applied directly to a data stream within the QPE. The benefit for developers is immediate and substantial: filtering logic that would previously have been written, tested, and maintained in middleware or the end application can now be handled natively by the engine. This not only reduces integration code complexity but also ensures that filtering rules are applied consistently at the source.
Complementing this was the addition of the 'send interval' parameter. When combined with the previously introduced batching capabilities, this feature provides deterministic control over data delivery cadence. For analytics platforms or reporting systems that require predictable data ingestion intervals, this allows the QPE to collect relevant events over a defined period and deliver them in a single, batched message at a reliable cadence.
Finally, version 9.5.1 introduced new data transformation options that further reduce the need for data wrangling in downstream applications:
• Date Formatting: The .iso and .isoutc options automatically convert timestamps to the standard ISO 8601 format.
• Key Renaming: The .as. option provides a simple mechanism for renaming JSON keys in the output. For example, $(tag.name.as.Name) could remap a standard field "tagName": "MyTagName" to a custom schema "Name": "MyTagName".
These seemingly small features have a significant practical value, as they offload common data mapping and schema alignment tasks from the integration layer into the QPE itself. The capabilities in 9.5.1 represent the most advanced expression of the “control” philosophy, providing a comprehensive toolkit for designing highly specific and efficient data streams.
Broadening the Scope:
Evolving APIs for System and Tag Management
A mature platform API must provide programmatic control not only over data output but also over the entire system’s configuration and operational state. In parallel with the evolution of its data streaming capabilities, the QPE API expanded to offer comprehensive commands for managing locators, tags, and the positioning engine itself, enabling deeper automation and more dynamic system control.
The APIs for locator and engine management followed a similar evolutionary path toward greater flexibility. In version 9.5.1, the legacy Get Locator information and Get Positioning Engine information commands were officially deprecated. They were replaced by the more capable Get Locator data and Get PE data commands, introduced in version 9.3.1. Much like the getTagData command, these new methods allowed developers to use custom output formats, providing tailored access to system and infrastructure state. This era also saw the addition of other key management commands in version 9.5.1, such as connectToQCP for dynamically controlling the connection to the Quuppa Customer Portal and enhancements to setLocatorIP, further cementing the API’s role in infrastructure management.
Tag management saw significant advancements, particularly with the introduction of support for the Quuppa V3 Protocol in version 8.0.0 (Jan 24th 2023). With V3 Protocol tags, the QPE automatically handles configuration based on tag group settings, significantly reducing the need for manual or API-driven configuration. For large-scale deployments with hundreds or thousands of tags, this feature dramatically reduces manual configuration effort, minimises human error, and ensures that all tags within a specific group operate with a consistent and correct configuration.
These enhancements demonstrate the API’s growth into a comprehensive system management interface. By exposing deep control over hardware, software, and tag behaviour, the API enables the automation of deployment, configuration, and maintenance tasks, empowering users to manage the entire Quuppa ecosystem more efficiently.
Conclusion:
The API as a Reflection of Platform Strategy
The evolution of the Quuppa Positioning Engine API is a compelling narrative of strategic focus. It chronicles a journey from a simple interface for pulling coordinates to a sophisticated, event-driven framework that provides deep control over data filtering, formatting, and delivery. This progression—from the foundational getTagData command, through event-based triggers, to in-engine transformation—is not merely an accumulation of features. It is the deliberate construction of the tools needed to turn raw signals into operational truth.
This technical evolution is a direct reflection of Quuppa’s broader strategy: a shift from being a technology provider to a solution enabler. The API provides the essential tools for developers to build the Reality Layer—a trustworthy, real-time digital representation of what is actually happening in a physical space, not what was supposed to happen. By empowering integrators to define relevance at the source, the API ensures this layer delivers actionable signals that enable customers to both operate with immediate, accurate decisions and optimise by learning from aggregated historical data.
For developers and system integrators, the ultimate value proposition of the modern QPE API is clear and multifaceted:
- Reduced Integration Complexity: By handling filtering, batching, and data transformation at the source, the API minimises the amount of custom code required in downstream applications and middleware.
- Improved System Performance: By enabling event-driven, purpose-built data streams, the API reduces unnecessary network traffic and lowers processing load on receiving enterprise systems.
- Faster Time-to-Value: By providing tools to translate raw location updates into meaningful business events directly within the QPE, the API enables rapid workflow development that delivers actionable insights, not just a seductive dot on a map.
As the primary interface to the Quuppa ecosystem, the API’s history demonstrates a clear commitment to empowering developers. It remains the critical enabler of control and innovation, ensuring the platform continues to deliver not just data, but a foundation for operational excellence.
Further reading
From Dots to Decisions: Event-Driven Data Integration in the Quuppa Positioning Engine
Read how the Quuppa Positioning Engine API can be used to define relevance at the source.
Product documentation: Output Targets, filtering, triggers, and batching
Practical guidance and configuration examples for designing event-driven data streams.