Testing in Production (API Dry Run)

Equinix Fabric supports an API Dry Run capability directly in the Production environment.
Dry Run lets you safely simulate supported API calls to verify request payloads, business logic, and resource availability without provisioning any infrastructure or incurring charges.

Use Dry Run when you are validating new integrations, testing changes to automation, or confirming that a complex request will succeed before you execute it “for real.”

How Dry Run Works

Dry Run is enabled by adding a query parameter such as dryRun=true to a supported API request.

When the Dry Run parameter is present, the Fabric platform performs server-side validation only, instead of completing the full transaction. Specifically, the platform will:

• Validate inputs – Check that required fields are present and correctly formatted, and that values such as Metros, IBX codes, bandwidth, and package types are valid.
• Verify business logic – Run external and internal checks, such as confirming that a Metro, Port, or Cloud Router is available for the requested operation.
• Skip persistence and provisioning – No database records are created, no work orders are generated, and no physical or logical resources are reserved, updated, or deleted.

Authentication, authorization, and quota checks are still enforced in the same way as a live call.

important

Dry Run does not bypass any permissions or account requirements. If your production call would be rejected due to missing entitlements or invalid account state, the Dry Run call will be rejected as well.

Supported Resources and Operations

Dry Run is available for specific Fabric v4 resources and operations.

Domain / Resource	API Endpoint	Supported Operations
Cloud Routers	/fabric/v4/routers	Create
Connections	/fabric/v4/connections	Create, Update
Networks	/fabric/v4/networks	Create
Ports	/fabric/v4/ports	Create, Update, Delete
Service Tokens	/fabric/v4/serviceTokens	Create, Update

For all other endpoints and operations, calls that include dryRun=true behave like standard production requests.

Understanding Dry Run Responses

The response returned by a Dry Run is designed to closely mirror what you would see from a live production call, with a few important differences.

Successful Validation

If the request passes all validation checks, the API returns 200 OK.

• Resource identifiers – Fields such as uuid or href may be null or omitted, because no resource is actually created during a Dry Run.
• Order numbers – No purchase order numbers or other commercial identifiers are generated.
• Side effects – No provisioning, modification, or deletion of resources takes place.

You can use this response to confirm that your payload structure, values, and requested state transitions are acceptable before submitting a live request without dryRun=true.

Validation Errors

If the request fails validation, the API returns the same HTTP status codes and error structures that a live production call would return (for example, 400 Bad Request for invalid input).

Typical validation failures include:

• Invalid location data – An unsupported or misspelled Metro or IBX code.
• Unsupported resource state transitions – Attempting to modify or delete a resource that is in a transient state such as PROVISIONING.
• Unmet dependencies – For example, trying to delete a Port that still has active Virtual Connections or Service Tokens associated with it.

These errors are returned during Dry Run without making any changes to production resources.

Using Dry Run with Ports

The /fabric/v4/ports endpoint exposes rich validation behavior when used with Dry Run.

Create Ports

Use the POST /fabric/v4/ports?dryRun=true operation when you submit a Dry Run create request for a Port:

• The API validates the requested Metro, IBX, and other location attributes.
• Package and interface properties (such as interfaceSpeed, bandwidth, and encapsulation) are checked for compatibility and availability.
• No physical port is reserved, and no order is created.

note

Bulk port creation is not supported via the public Fabric API. Each Dry Run create request should describe a single Port.

Update Ports

Use the PATCH /fabric/v4/ports/{uuid}?dryRun=true operation to safely test Port configuration changes before applying them:

• You can validate updates to a Port’s descriptive properties (for example, name) or configuration attributes such as encapsulation.
• The API enforces state rules: attempts to update a Port that is in a transient state (such as PROVISIONING) will return an error. The Port must typically be in an ACTIVE state for most updates.
• Dependency rules are also enforced: for example, you cannot change encapsulation if the Port has existing connections or Service Profiles that would be invalidated by the change.

No changes are applied to the Port during a Dry Run; you only receive the validation result and any associated error messages.

Delete Ports

Use the DELETE /fabric/v4/ports/{uuid}?dryRun=true operation to validate whether a delete request would succeed:

• The API checks that the Port exists and is in a state that allows deletion (typically ACTIVE).
• The API ensures that no active connections, Service Tokens, or other dependent services are still bound to the Port.

If any dependencies are detected, the Dry Run delete call returns the same error that a live delete request would return, without removing or modifying the Port.

When to Use Dry Run

Consider using Dry Run in these scenarios:

• Before rolling out new automation – Validate that generated API requests are structurally correct and respect Fabric business rules.
• When testing in production – Confirm that real account data (Ports, Connections, Networks, Cloud Routers, and Service Tokens) supports the intended operation before executing it.
• For troubleshooting – Reproduce failing scenarios safely to understand which validation rule or dependency is blocking a change.

After a successful Dry Run and any necessary adjustments, you can resend the same request without dryRun=true to perform the actual operation.