> For the complete documentation index, see [llms.txt](https://navixy.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://navixy.com/docs/navixy-graphql-api/products/iot-logic/api-reference.md).

# IoT Logic API reference

How the IoT Logic reference is organized: one page for flows, with their node types, transitions, inputs, queries, and mutations.

The IoT Logic API reference documents every operation and type of IoT Logic. All of them are on one page, [Flows](/docs/navixy-graphql-api/products/iot-logic/api-reference/flows.md), because every IoT Logic type belongs to a flow. The page covers the queries and mutations, the object and input types, and the enums, with a field table for every type.

The reference states what each operation and field is. For how to use them together, see the [IoT Logic guides](/docs/navixy-graphql-api/products/iot-logic/guides.md), and for the GraphQL fundamentals behind the notation, see [GraphQL basics](/docs/navixy-graphql-api/graphql-basics.md), including the [type syntax](/docs/navixy-graphql-api/graphql-basics.md#type-syntax) that the field tables use.

## Where the operations live

All IoT Logic queries are nested under the `iotLogic` field of the `Query` type, and all mutations under the `iotLogic` field of the `Mutation` type. Every response has the same shape under `data.iotLogic`. Every operation acts in the workspace that your access token names, so no query or mutation takes a workspace ID. For what the product covers and how to start, see the [product overview](/docs/navixy-graphql-api/products/iot-logic.md).

A flow is also a `Node`, so the common [`node` and `nodes`](/docs/navixy-graphql-api/core-api-reference/common.md) queries return flows by ID. The nodes in the graph of a flow are a different type, `IotLogicFlowNode`, and you read them only through their flow.

## Pages

<table><thead><tr><th width="186">Page</th><th>Covers</th></tr></thead><tbody><tr><td><a href="/docs/navixy-graphql-api/products/iot-logic/api-reference/flows.md">Flows</a></td><td><code>IotLogicFlow</code>, the <code>IotLogicFlowNode</code> interface with its node types, the actions and the device mapping of a Device Action node with the <code>IotLogicDeviceCommandAction</code> union, <code>IotLogicFlowTransition</code>, the <code>flow</code> and <code>flows</code> queries with their filter and order inputs, the <code>deviceFlowLinks</code> query with <code>IotLogicDeviceFlowLink</code> and its filter and order inputs, the <code>deviceAttributes</code> query with <code>IotLogicDeviceAttributes</code> and <code>IotLogicDeviceAttribute</code>, the <code>flowDebugValues</code> query with <code>IotLogicFlowDebugValues</code>, and the <code>flowCreate</code>, <code>flowUpdate</code>, and <code>flowDelete</code> mutations with their inputs.</td></tr></tbody></table>

## Shared types

The scalars, interfaces, and pagination types that IoT Logic shares with the other products are on the [Common resources](/docs/navixy-graphql-api/core-api-reference/common.md) page. The devices of a data source are `Device` records from Business Data Repository, documented on the [Devices](/docs/navixy-graphql-api/products/business-data-repository/api-reference/devices.md) page. The [Core API reference](/docs/navixy-graphql-api/core-api-reference.md) indexes the reference pages of every product.

## How the reference pages are structured

The page follows the same order as every reference page: queries, then mutations, then objects, inputs, enums, interfaces, and unions, with pagination types in a section of their own at the end. Field tables use the GraphQL type notation, where `!` marks a value that is never null and `[...]` marks a list: see [Type syntax](/docs/navixy-graphql-api/graphql-basics.md#type-syntax).

## Other ways to explore the API

* [Public GraphQL schema](/docs/navixy-graphql-api/developer-resources/public-graphql-schema.md): The full type system split into several files.
* [Introspection](/docs/navixy-graphql-api/graphql-basics.md#introspection): Explore the schema from your own GraphQL client.

## See also

* [IoT Logic overview](/docs/navixy-graphql-api/products/iot-logic.md): Learn what IoT Logic covers and how its concepts fit together.
* [IoT Logic node types](/docs/navixy-graphql-api/products/iot-logic/node-types.md): Read the fields, the behavior, and the rules of each node type in one place.
* [IoT Logic guides](/docs/navixy-graphql-api/products/iot-logic/guides.md): Build a flow from these operations, and handle the errors that a write returns.
* [Optimistic locking](/docs/navixy-graphql-api/optimistic-locking.md): Learn about the version check that every flow update and delete makes.
* [Error handling](/docs/navixy-graphql-api/error-handling.md): See the error structure, the codes, and the common error scenarios.


---

# 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://navixy.com/docs/navixy-graphql-api/products/iot-logic/api-reference.md?ask=<question>&goal=<user_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.