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

# Terraform reference

# Doc Type: Terraform Reference

> **Tier**: Reference | **Reader phase**: Refining & Details\
> **Back to tier overview**: [reference/index.md](index.md)

***

## What it is

Terraform Reference documents describe **the Aviatrix Terraform provider, its resources, and its data sources**. They are the authoritative source for developers and engineers writing Terraform to deploy and manage Aviatrix infrastructure.

The primary Terraform reference lives in the [Terraform Registry](https://registry.terraform.io/providers/AviatrixSystems/aviatrix/latest/docs) and is generated from the provider source code. Aviatrix documentation pages in this category serve as **entry points, supplements, and navigational aids** — not duplicates of the Registry content.

There are two document sub-types:

* **Provider Reference** — Points to the Terraform Registry; may include notes about provider versioning, authentication, and Aviatrix-specific configuration not covered in the Registry
* **Module Reference** — Documents Aviatrix-published Terraform modules: what they provision, their inputs and outputs, and when to use them vs. raw provider resources

***

## Goal

After reading a Terraform Reference document, the reader can configure the Aviatrix Terraform provider or module and locate the resource and attribute documentation they need to write working infrastructure-as-code. For Module Reference docs specifically: the reader understands what the module provisions, what inputs it requires, and what outputs it produces.

***

## Primary personas

| Persona | How they use it |
| - | - |
| **Developer** | Primary audience. Uses to understand provider capabilities and write Terraform |
| **Engineer** | Uses when implementing a Configuration Guide via the Terraform modality |

***

## When to create a new Terraform Reference document

* Create a **Provider Reference** page once per major provider version. Update in place for minor versions.
* Create a **Module Reference** page for each Aviatrix-published module, when the module is published to the Terraform Registry or GitHub.

Do not duplicate Terraform Registry content in these pages. Link to the Registry as the canonical source for resource attribute reference.

***

## Required sections — Provider Reference

1. **Overview** — 2–3 sentences: what the provider covers, where it is hosted, and the current stable version.
2. **Getting Started** — Link to the Terraform Registry provider page and the Aviatrix Terraform quickstart guide. Include a minimal provider configuration block as a code example.
3. **Authentication** — How to configure provider authentication to the Aviatrix controller (endpoint, credentials). This is the most common point of confusion not covered in the Registry.
4. **Version Compatibility** — A table mapping provider versions to compatible Aviatrix controller versions.
5. **Resources and Data Sources** — A brief categorized list (or link to the Registry index) of available resources and data sources.

***

## Required sections — Module Reference

1. **Overview** — What this module provisions, what problem it solves, and when to use it vs. composing raw provider resources.
2. **Usage** — A minimal working example as a Terraform code block.
3. **Inputs** — A table of input variables: **Variable** | **Type** | **Default** | **Description** | **Required**.
4. **Outputs** — A table of output values: **Output** | **Type** | **Description**.
5. **Requirements** — Minimum Terraform version, minimum Aviatrix provider version, cloud provider prerequisites.
6. **Source** — Links to the Terraform Registry module page and GitHub repository.

***

## Tone & voice

**Technical and terse.** Terraform Reference docs are looked up, not read. Input and output descriptions should be single sentences. Usage examples should be minimal and functional — not comprehensive demonstrations. Notes and caveats belong in `<Note>` callouts, not inline with descriptions.

***

## Length guidance

* **Provider Reference**: 50–120 lines. Most detail lives in the Registry — this page is a gateway.
* **Module Reference**: 80–200 lines. Input/output tables dominate the length; keep prose minimal.

***

## Frontmatter

See [Frontmatter Standards](../frontmatter.md) for field definitions and formatting rules.

Title naming conventions by sub-type:

* **Provider Reference**: `Aviatrix Terraform Provider`
* **Module Reference**: The module name as published. Example: `terraform-aviatrix-mc-transit`.

```yaml theme={null}
---
title: "[Provider or Module Name]"
description: "Reference for the Aviatrix [Terraform provider / module-name] — covering [authentication/inputs/outputs] and compatibility."
---
```

***

## Mintlify components

See [Style Guide](../style-guide.md) for component definitions and usage rules.

Use HCL code blocks for configuration and module usage examples, tables for inputs/outputs and version compatibility, `<Note>` for version-specific behavior, and `<Warning>` for breaking changes between provider versions.

***

## Linking

* **Link in from**: Configuration Guides (Terraform tab), Component docs (Linking section)
* **Link out to**: Terraform Registry (canonical resource reference), GitHub module repository

***

## Dos and don'ts

| Do | Don't |
| - | - |
| Link to the Terraform Registry as the canonical attribute reference | Duplicate full resource attribute tables from the Registry |
| Include a working minimal provider configuration example | Include an example that requires non-obvious prerequisites to run |
| Document version compatibility explicitly | Leave readers to discover compatibility issues at apply time |
| Note breaking changes between provider versions prominently | Bury breaking changes in a table row |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.