> ## Documentation Index
> Fetch the complete documentation index at: https://docs.alumio.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Introduction

> Understand how an Alumio integration is put together and how to deliver it as an importable NDJSON file.

This guide explains how to build an Alumio integration manually and package it as an importable configuration file.

You can build everything described here directly in the Alumio dashboard. This guide focuses on the underlying
configurations and the import file.

## Configurations

Every building block (a route, an incoming or outgoing configuration, a transformer, an HTTP client, a schedule, and so on) is a **configuration**. A configuration is a JSON object of a specific **type**, stored under an **identifier**.

Configurations can be imported and exported as **NDJSON** (newline-delimited JSON), with one configuration object per line.

## The NDJSON file

An Alumio import file is newline-delimited JSON (NDJSON): one configuration per line. The export endpoints produce the exact same format, so any file you export is directly re-importable.

Each line wraps a single configuration in a standard envelope:

```json theme={null}
{
  "$schema": "https://di.schema.alumio.com/register.configuration.json",
  "type": "route-configuration",
  "identifier": "example-import-export",
  "name": "Example Import Export",
  "description": "",
  "object": { },
  "owner": null,
  "disabled": false,
  "label": null
}
```

| Field         | Required | Notes                                                                                                                                                 |
| ------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| `$schema`     | Yes      | Always `https://di.schema.alumio.com/register.configuration.json`                                                                                     |
| `type`        | Yes      | The configuration type, for example `route-configuration` or `http-client`                                                                            |
| `identifier`  | Yes      | Unique within the type; see the identifier rules below                                                                                                |
| `name`        | Yes      | Human-readable display name                                                                                                                           |
| `object`      | Yes      | The actual configuration (see below)                                                                                                                  |
| `description` | No       | Free text shown in the dashboard; use it to explain intent                                                                                            |
| `disabled`    | No       | Defaults to `false`                                                                                                                                   |
| `owner`       | No       | Identifier of a parent configuration that owns this one (children are cascade-deleted with the parent). Normally `null` for hand-built configurations |
| `label`       | No       | Array of label-name strings, or `null`                                                                                                                |

## Identifier rules

The identifier pattern is `^[a-z0-9]+[a-z0-9\-]*[a-z0-9]+$`: lowercase letters, digits, and hyphens; at least two characters; must start and end with a letter or digit.

Uniqueness is per type. An `http-client` and an `incoming-configuration` may share the same identifier.

## The object field

The `object` field holds the actual configuration: a `prototype` plus its `parameters`. See the
[configuration object](/guides/building-integrations/building-the-configuration-object) page for
a guide on how to build the object field.