Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.equinix.dev/llms.txt

Use this file to discover all available pages before exploring further.

If you’ve already deployed Equinix resources — through the portal, the API, or hand-written Terraform — equinix.dev can adopt them via standard terraform import. This page walks through the canonical patterns.

​
Discovery

First, find the UUIDs of the resources you want to import. Three options:
Each resource page shows its UUID near the top, format xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Click the copy icon.
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://api.equinix.com/fabric/v4/cloudRouters?metro_code=DC" \
  | jq '.data[] | {uuid, name, package: .package.code}'

{
  "tool": "search_router",
  "arguments": { "metro_code": "DC", "owner_account": "${EQUINIX_ACCOUNT_NUMBER}" },
  "result": {
    "routers": [
      { "uuid": "abc123-...", "name": "fcr-existing-iad", "package": "BASIC" }
    ]
  }
}

​
Import a Fabric Cloud Router

terraform import equinix_fabric_cloud_router.fcr_iad <uuid>
The import only attaches state — it doesn’t fill in the HCL. Run terraform plan after; differences will show what’s missing in your .tf files. The resource shape: 
resource "equinix_fabric_cloud_router" "fcr_iad" {
  name = "fcr-existing-iad"
  type = "XF_ROUTER"
  package { code = "BASIC" }
  location { metro_code = "DC" }
  account { account_number = var.equinix_account_number }
  notifications {
    type   = "ALL"
    emails = ["platform@example.com"]
  }
  lifecycle { ignore_changes = [account, change_log] }
}

​
Import a Fabric Connection

terraform import equinix_fabric_connection.aws_iad <uuid>
After import, mirror the existing connection’s settings in HCL — bandwidth, redundancy priority, A-side and Z-side access points.

​
Import a Network Edge device

terraform import equinix_network_device.fortigate_iad <uuid>
Note: device imports come with the SSH key references. If those aren’t in your Terraform state, the next plan will try to drop and re-add them. Pin SSH keys via lifecycle { ignore_changes = [ssh_key] } if you don’t want to manage them in Terraform.

​
Import a Route Filter

terraform import equinix_fabric_route_filter.pci_only <uuid>
The rules import via a separate command per rule: 
terraform import equinix_fabric_route_filter_rule.pci_only_rule_1 <route_filter_uuid>/<rule_uuid>

​
Import a Stream Subscription

terraform import equinix_fabric_stream_subscription.metro_telemetry["iad"] <uuid>
For for_each resources, quote the key: equinix_fabric_stream_subscription.metro_telemetry[\"iad\"].

​
Bulk imports via a script

For accounts with dozens of existing resources, scripted imports are faster: 
#!/usr/bin/env bash
set -euo pipefail

# Dump UUIDs from the portal API.
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://api.equinix.com/fabric/v4/cloudRouters" \
  | jq -r '.data[] | "\(.name)\t\(.uuid)"' \
  | while IFS=$'\t' read -r name uuid; do
      slug=$(echo "$name" | tr '[:upper:]' '[:lower:]' | tr -c 'a-z0-9' '_' | sed 's/^_*//;s/_*$//')
      echo terraform import "equinix_fabric_cloud_router.${slug}" "${uuid}"
  done
Save the output, sanity-check the slugs, then bash ./imports.sh to run them.

​
After import: clean up state drift

The first terraform plan after import will likely show “diffs” that aren’t really drift — they’re shape mismatches between portal-emitted JSON and our HCL. Walk each one:
  • If the HCL is right and the server has stale data → run a terraform apply to reconcile.
  • If the server is right and the HCL is wrong → fix the HCL.
  • If the diff is one of the known gotchas → add the lifecycle { ignore_changes = [...] } block.
After the dust settles, you’ll have an empty plan and clean state.

​
Next

MCP-driven workflow

Have an agent author imports + Terraform via the Equinix MCP.

Recipes

Ground-truth examples that compose the imported resources.