Provisioning Bare Metal Through an API Without Opening a Ticket

A common reason teams hesitate to move off public cloud is losing programmatic control. On AWS or Google Cloud, a new server is an API call. At many dedicated hosting providers, it’s still a form, an email, or a ticket. OpenMetal Central’s public API, introduced in the February 2026 release and expanded in July, closes that gap for bare metal: you can check stock, order hardware, apply a standard OS configuration, and track the build to completion from a script.

The problem is concrete. If a platform team provisions everything from pipelines, a server that requires a ticket doesn’t fit, no matter how good the economics are. That used to be a fair description of dedicated servers. This article walks through what the OpenMetal API supports today, using our public API reference, so you can judge whether it fits your automation.

What The Central API Covers

The February 2026 Central release introduced the public API, OAuth applications, scoped API keys, and a dedicated sandbox. The July 2026 release added SSH key management, ramdisk deployment configurations with a metadata service, and documented organization management endpoints.

Taken together, the API’s core endpoint groups cover:

• Inventory: available locations, per-location hardware availability, and the product catalog with pricing
• Deployment: available OS images per location
• Configurations: reusable deployment templates with an OS image and cloud-init data
• SSH keys: stored public keys you can reference by ID in orders
• Orders: creating new bare metal or private cloud orders and tracking their status
• Clouds: listing clusters, retrieving detailed stats, adding and removing hardware, and deleting
• Nodes: power control and IPMI console sessions
• VLANs and IP blocks: network provisioning (covered in its own article)
• Accounts and organizations: profile data and member management

In our API, a “cloud” is a collection of servers. That covers both a Private Cloud Core running OpenStack and a group of bare metal nodes, so the same endpoints work for either.

Authentication And Access Control

The API uses bearer tokens, and there are two ways to get one.

API Keys

API keys are long-lived tokens generated in Central under Organization Dashboard, Organization Tools, API Keys. You use the key directly as the bearer token. Keys can carry read, write, or manage permissions scoped to your organization, and they support IP address restrictions, including CIDR blocks.

That IP restriction is worth using. A key locked to your CI runners’ egress range is far less dangerous if it ever leaks.

OAuth Client Credentials

For services that shouldn’t hold a long-lived secret, you can create an OAuth client in the same place and receive a client ID and client secret. You exchange those for a short-lived bearer token at the /v1/oauth2/token endpoint using the client credentials grant, which is defined in section 4.4 of RFC 6749. The sample response in our API reference shows an expires_in of 14,400 seconds.

curl --location \
  'https://api.central.openmetal.io/v1/oauth2/token?grant_type=client_credentials' \
  --header 'Authorization: Basic <Base64-encoded client_id:client_secret>'

Permissions That Map to Real Roles

Several endpoints enforce specific roles, and it helps to know them before you design service accounts:

• Deleting a cloud or removing a hardware node requires manage permission.
• Retrieving a cloud’s billing subscription requires billing permission, which the manage and orgBilling roles hold.
• Most read endpoints return a 403 if the caller lacks read permission on the resource.

A practical pattern: give your provisioning pipeline a write-scoped key restricted to its IP range, and keep manage-level credentials (which can delete infrastructure) in a separate, tightly held key.

Audit Visibility

The February release also added audit logging to Central. The Audit Logs page shows key actions performed by users in your organization, giving you a record of who did what and when. If you’re rolling out API access across a team, that’s where you confirm the activity matches what you expect.

Test Against The Sandbox First

Every endpoint in the API reference has two servers: production at api.central.openmetal.io and a sandbox at sandbox.api.central.openmetal.io. You generate sandbox credentials directly from Central.

The sandbox is built for testing integrations without touching production, and sandbox and production behavior are kept consistent. That matters for bare metal more than for cloud VMs, because a production mistake here is a real server order. Build your scripts against the sandbox, then switch the base URL.

The Provisioning Workflow, Step By Step

Creating a server order follows a specific workflow. Here it is with the supporting calls that make it practical.

Step 1: Find Locations and Check Availability

Start with GET /v2/inventory/locations, which returns OpenMetal’s datacenter locations and their pod identifiers. Then call GET /v2/inventory/{pod_location}/availability for the location you want.

The availability response returns each hardware SKU with two numbers:

• count: the total number of available servers of that type
• max_size: the number of available servers that can be deployed while maintaining distribution across cabinets for redundancy

The second number is the one to plan around. If you’re building a cluster that needs to survive a cabinet-level failure, max_size tells you how many nodes you can place with that distribution intact. That’s the kind of detail you rarely get from a provider’s order form.

Both endpoints are useful for multi-region planning. If your capacity plan spans the US, Amsterdam, and Singapore, you can query all of them in one script before committing to where a cluster lands.

Step 2: Look Up Products, Pricing, and OS Images

GET /v1/products returns the product catalog, including hardware specifications, add-ons like memory, drives, and IP blocks, and pricing. It’s a public endpoint that doesn’t require authentication, and it accepts a location parameter for location-specific pricing. GET /v1/deployment/node/images/{pod_location} returns the OS images available at a location, along with image hashes. That endpoint is also public.

Pulling pricing from the catalog endpoint rather than hardcoding it keeps any cost estimates in your tooling in sync with what OpenMetal is actually charging. OpenMetal uses fixed monthly pricing based on dedicated hardware rather than usage metering, so once you know the configuration, you know the bill. The bare metal pricing page shows the same catalog in a browser.

Step 3: Store SSH Keys and Deployment Configurations

Two resources make orders repeatable.

SSH keys: POST /v1/public-keys stores a public key. Supported key types include ssh-ed25519, ssh-rsa, the ecdsa-sha2 variants, and hardware-backed security key formats. The key is validated on creation and a SHA256 fingerprint is computed automatically. Once stored, you reference keys by ID in orders instead of pasting raw key data.

Deployment configurations: POST /v1/configurations creates a reusable template containing an OS image and cloud-init user data. A disk-mode configuration requires the image URL plus a hash algorithm (md5, sha256, or sha512) and hash value for integrity verification. As of July, configurations can also use a ramdisk mode that boots the OS into memory. We cover that in detail in How to Run Bare Metal Servers That Boot Entirely From Memory.

Step 4: Place the Order

POST /v1/orders creates the order. Each item specifies a hardware SKU, a location, a type (baremetal or pcc), and a quantity. For bare metal, you add either an operating system or a deployment configuration in the modifications block. Modifications are only supported for bare metal products.

{
  "label": "ci-runners-batch-01",
  "description": "Self-hosted CI runner pool",
  "fields": {
    "items": [
      {
        "hardware_sku": "<sku from availability endpoint>",
        "location": "<pod_location>",
        "type": "baremetal",
        "quantity": 3,
        "modifications": {
          "deployment_configuration": "<configuration id>"
        }
      }
    ],
    "config_options": {
      "public_key_ids": ["<saved key id>"]
    }
  }
}

Use the SKU identifiers the availability endpoint returns rather than guessing names, since the lineup changes as new hardware generations are added.

Step 5: Poll Until Provisioning Completes

GET /v1/orders/{orderId} returns the order with a clouds_deployed array. Each entry includes the cloud ID and a provisioning status that moves through this sequence:

pending → in_progress → awaiting_setup → complete

If errors occur during provisioning, the cloud may enter a manual_setup state that requires support intervention. Your pipeline should handle that state explicitly, alert someone, and stop, rather than polling forever.

Step 6: Read Back What You Got

Once you have the cloud ID, GET /v1/clouds/{cloudId}/stats returns detailed information: node hardware, power states, VLAN configuration, IP addresses, and service assignments. For a Private Cloud Core, the response also shows which nodes run which OpenStack and Ceph services. That output is what you’d feed into an inventory system, a configuration management tool, or the next stage of a pipeline that installs your workloads.

Scaling, Operating, And Retiring Infrastructure

Provisioning is only the first day. The API covers the rest of the lifecycle too.

Adding Nodes to an Existing Cluster

To grow a cluster, submit an order with a cloud_id on the item. The conditions: the cloud must belong to your organization, the location must match the cloud’s location, the type must match the cloud’s type, and the cloud must be fully provisioned before you add nodes. Billing attaches to the existing cloud.

The July release brought the Central UI in line with this. Adding hardware now routes through the standard checkout flow, with a cloud selector pre-populated when you click “Add Hardware.” The July release also fixed a bug that had caused bare metal node additions to fail validation when the quantity was greater than one.

For Private Cloud Cores, it takes around 45 seconds to deploy a new cloud and about 20 minutes to add a server to an existing cluster when hardware is available.

Power Control and Console Access

POST /v1/deployment/cloud/{cloudId}/node/{nodeUuid}/power changes a node’s power state to power on, power off, or rebooting. For hands-on troubleshooting, the API can generate an IPMI console session, either as an HTML5 browser console URL (the recommended method) or as a JNLP file for the Java-based console.

The Central UI also offers graceful reboots and graceful power-offs, added in February, and a Reprovision tool that reinstalls a node already in your cluster with a different OS or deployment configuration without replacing the hardware.

Removing Nodes and Decommissioning

DELETE /v1/clouds/{cloudId}/hardware/{nodeUuid} removes a single node from a cloud, with inventory cleanup handled asynchronously. DELETE /v1/clouds/{cloudId} deletes the whole cloud.

Deleting a cloud has a safety window built in. The cloud is deactivated immediately, but servers aren’t fully decommissioned and wiped for three days. During that period, the cloud sits in a pending-delete state. That’s a useful backstop against a pipeline that tears down the wrong environment, but plan your teardown automation around it, since the hardware isn’t gone the moment the call returns.

What This Looks Like In Practice

Two patterns come up often.

A Platform Team Replacing Tickets With a Pipeline

A platform team that already provisions public cloud through CI can treat bare metal the same way. A pipeline job checks availability in the target location, compares max_size against the cluster size it needs, places the order with a standard deployment configuration and the team’s stored SSH keys, polls to complete, and hands the node list from the stats endpoint to Ansible or whatever runs next. If you’re also automating the OpenStack layer of a private cloud, our guide on building repeatable private clouds with Terraform covers that side.

An MSP Standing Up Customer Environments

Managed service providers building customer environments on dedicated hardware need the same thing done many times, correctly. Deployment configurations give every customer the same hardened baseline. The organization endpoints let you manage members programmatically. Scoped, IP-restricted API keys keep automation access narrow. OpenMetal’s MSP program is built around that kind of repeatable, multi-customer model.

What Still Needs A Human

Being honest about the limits helps you design around them:

• Failed provisioning: a manual_setup status means support needs to step in.
• Hardware SKU planning: the API tells you what’s in stock. It won’t tell you which server is right for your workload. That’s still a conversation, and OpenMetal’s engineers are available for it.
• Anything not in the API reference: if a task isn’t documented as an endpoint, assume it’s done in the Central UI or with support. Some features, like the Reprovision tool and graceful power actions, are Central UI features.

Our documentation site is also searchable as of July, with an AI agent that searches the docs and tries to answer questions, which helps when you’re working out how an endpoint behaves.

Who This Is For

A good fit if you:

• Provision infrastructure from CI pipelines or internal platforms today
• Are moving workloads off public cloud and need to keep API-driven provisioning
• Build many similar environments, such as MSP customer stacks or per-team clusters
• Care about cabinet-level redundancy and want to plan node placement with real availability data
• Want fixed monthly pricing without giving up automation

Probably not the right fit if you:

• Need per-second, spin-up-and-destroy compute for bursts measured in minutes
• Want a fully managed platform where you never touch the server layer
• Need an infrastructure operation the API doesn’t document yet and can’t route through the UI or support

The Short Version

Bare metal stops feeling like old-school hosting once you can order it, configure it, and track it from the same pipeline that runs everything else. The OpenMetal API gives you that path while keeping the fixed pricing and dedicated hardware that make bare metal worth choosing in the first place.

To try it without risk, build against the sandbox, then apply for a proof of concept to run your pipeline against real hardware. You can compare configurations on the bare metal pricing page or contact our team to talk through a migration.

Frequently Asked Questions

Does OpenMetal have an API for provisioning bare metal servers?

Yes. The OpenMetal Central public API supports checking inventory by location, creating bare metal and private cloud orders, applying deployment configurations and saved SSH keys, tracking provisioning status, adding and removing nodes, controlling power, opening IPMI console sessions, and deleting clouds. The full API reference is at openmetal.io/docs/manuals/api.

How do I authenticate to the OpenMetal API?

You can use a long-lived API key generated in Central, or create an OAuth client and exchange its client ID and secret for a short-lived bearer token using the client credentials grant. API keys can carry read, write, or manage permissions and can be restricted to specific IP addresses or CIDR blocks.

Is there a sandbox for testing the OpenMetal API?

Yes. Every endpoint is available on a sandbox server at sandbox.api.central.openmetal.io, and you can generate sandbox credentials from Central. OpenMetal states that sandbox and production behavior stay consistent, so you can build and test integrations before running them against production.

What does max_size mean in the inventory availability response?

The availability endpoint returns two values per hardware SKU. count is the total number of available servers. max_size is the number that can be deployed while keeping the servers distributed across cabinets for redundancy, which is the more useful number when you’re planning a fault-tolerant cluster.

How do I know when a bare metal order is finished?

Poll the order with GET /v1/orders/{orderId} and check the provisioning status in the clouds_deployed array. It moves from pending to in_progress to awaiting_setup to complete. If it reaches manual_setup, provisioning hit an error and needs support.

Can I add servers to an existing cluster through the API?

Yes. Include the existing cloud’s ID on the order item. The cloud must be owned by your organization and fully provisioned, and the location and type must match the existing cloud. Billing attaches to that cloud.

What happens when I delete a cloud through the API?

The cloud is deactivated immediately and enters a pending-delete state. Servers are fully decommissioned and wiped after a three-day delay.