> For the complete documentation index, see [llms.txt](https://docs.akenza.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.akenza.io/reference/reference.md). # Overview The APIs, scripting runtime, and notations for working with akenza programmatically. This section is the technical detail behind the rest of the documentation: the interfaces for reaching akenza from your own code, the runtime your scripts execute in, and the notations used in the interface. ## Reaching akenza from your own code


	REST API	Programmatic access to the platform, with example projects in Python, JavaScript, and Java.	REST API
	WebSocket API	Subscribe to a live sensor data feed instead of polling for new data.	WebSocket API

The two answer different questions. The **REST API** is for asking what the state is, or for changing it: reading device data over a period, creating devices, managing a fleet from your own system. The **WebSocket API** is for being told when something arrives, so a client reacts to an uplink rather than checking for one. Both are scoped to an organization and authenticated with credentials issued there. {% content-ref url="/pages/rsPlVY9mNp2Ei3bWr8We" %} [API keys](/device-management/managing-an-organization/api-keys.md) {% endcontent-ref %} ## Writing scripts [Scripting](/reference/scripting.md) covers the JavaScript runtime that akenza executes as part of a data flow, in three places: * An **uplink decoder** turns a raw device payload into structured, readable data. * A **downlink encoder** turns a readable command back into the format a device expects. * A **custom logic block** evaluates logic in the [rule engine](/device-management/rule-engine.md) to decide whether an action should fire. All three implement the same `consume(event)` entry point and emit their result, so the shape of a script is the same wherever it runs.


Scripting	The runtime, the script structure, the emit function, and what is restricted.	Scripting
Stateful Operations	Carrying state between executions, which a script does not keep on its own.	Stateful Operations
Utility Functions	The helpers available inside a script.	Utility Functions

{% hint style="info" %} Each execution loads the script fresh, so variables do not survive from one run to the next. Anything that has to persist between uplinks belongs in [stateful operations](/reference/scripting/stateful-operations.md). {% endhint %} ## Notations

Page	What it covers
Payload Templating	The `{{ }}` syntax for inserting sample data and metadata into output connector payloads and rule actions, such as putting a measured value into an email subject.
Time Range Selector	The DateMath notation behind absolute, relative, and predefined time ranges.

## Working with stored data Several reference pages concern the data akenza has stored rather than the devices that sent it:

Page	What it covers
Querying Device Data	Reading measurements back, including the aggregations used for occupancy.
Filtering	Narrowing what an API call returns.
Schema inference	How akenza derives the structure and measurement types of incoming data.
Authentication	Obtaining and using a token for API requests.

{% hint style="warning" %} All of this reads what has been stored. A [data flow](/device-management/your-data-flow.md) that forwards uplinks elsewhere without also using the [akenza DB](/device-management/your-data-flow/connectors/databases/akenza-db.md) output connector leaves nothing for these APIs to return, and no inserts for the WebSocket API to announce. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.akenza.io/reference/reference.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.