On a fresh Port org, terraform apply fails or conflicts with live state because out-of-the-box (OOTB) objects (blueprints, pages, scorecards) are pre-created and must be manually imported before Terraform can manage them. There is no documented canonical inventory or tooling to automate this process.

Problem

When a customer starts managing a new Port org with the Terraform provider, they immediately encounter conflicts because OOTB resources (e.g., port_blueprint.service, port_blueprint.team, port_page.home) already exist in the org but are not in Terraform state. This forces a manual, error-prone import process for every environment.

Compounding this, OOTB resource sets differ between orgs created at different points in time (due to Port's active development), causing drift between environments and forcing customers to maintain env-specific import files and conditional branches in shared Terraform modules.

There is currently no documented greenfield org inventory, no ready-made import blocks, and no tooling to automate the bootstrap process.

Current Behavior

terraform apply on a fresh org fails or fights live state due to pre-existing OOTB resources.

Customers must manually identify every OOTB resource and run terraform import for each one before normal Terraform operations are possible.

No canonical list of OOTB resource IDs or ready-made import blocks is published.

No CLI tooling exists to emit import IDs or HCL skeletons for an existing org.

Expected Behavior / Ask

Publish a canonical greenfield org inventory — a documented, versioned list of all OOTB resource IDs (blueprints, pages, scorecards, etc.) with ready-made Terraform import blocks.

Provide a bootstrap/export CLI — a tool that inspects an existing Port org and emits:

Import IDs for all existing resources.

HCL skeleton resource blocks ready to paste into a Terraform module.