Getting started

From nothing to a running server, in the order you will actually do it. Every call here is real - copy them as they are and substitute your own token.

1. Issue a token

Open API tokens in your client area, pick the project you want to manage, and choose an access level. Take read first if you only want to look around; you can issue a second token with write access when you are ready to create things.

The secret is shown once. We keep only its fingerprint, so a lost token is replaced, not recovered.

2. Make sure it works

curl -H "Authorization: Bearer $FBX_TOKEN" \
     https://api.fiberax.com/v1/project

You should get your project back:

{ "data": { "id": 1201, "name": "My Data Center", "status": "Active" } }

If this returns 401, the token is wrong or revoked. If it returns 403, the token is fine but its access level is lower than the call needs.

3. Look at what you can create

Server types differ in how they are sized, and that changes what the create call must carry. Read them first:

curl -H "Authorization: Bearer $FBX_TOKEN" \
     https://api.fiberax.com/v1/server-types

There are three ways a type can be sized, and the mode says which one applies. A type with "pricing_mode": "plans" is bought by the plan - you send plan_id and must not send cores, memory_mb or disk_gb. A type with "pricing_mode": "sliders" is the other way round: the three numbers, no plan. A type with "pricing_mode": "fixed" is bought as a ready package - one field, gpu_package, and the size fields are refused next to it (see GPU servers). Sending the wrong set is refused with 422 rather than quietly interpreted.

Then list the images that type offers, and the prices:

curl -H "Authorization: Bearer $FBX_TOKEN" \
     "https://api.fiberax.com/v1/server-types/4/images"

curl -H "Authorization: Bearer $FBX_TOKEN" \
     "https://api.fiberax.com/v1/server-types/4/pricing"

The image list also contains your own uploaded ISO images, marked "type": "useriso" and identified as uiso-N. A server cannot be created from one of those - the request is refused with image_not_supported. An ISO installs a machine rather than builds one: create the server from an operating system image and insert the ISO into its drive afterwards.

4. Add your SSH key

Keys live in your account pool, so this is done once and every project sees them:

curl -X POST -H "Authorization: Bearer $FBX_TOKEN" \
     -H "Content-Type: application/json" \
     -d '{"name":"laptop","public_key":"ssh-ed25519 AAAA... you@laptop"}' \
     https://api.fiberax.com/v1/ssh-keys

5. Create a server

On a slider type, with a fresh public address and your key:

curl -X POST -H "Authorization: Bearer $FBX_TOKEN" \
     -H "Content-Type: application/json" \
     -H "Idempotency-Key: first-server-2026-08-19" \
     -d '{
       "name": "web-01",
       "server_type_id": 4,
       "image": "fcf9f69c8630904c1d6d73a821f4e674",
       "cores": 2,
       "memory_mb": 4096,
       "disk_gb": 40,
       "public_ipv4": { "new": true },
       "ssh_keys": [13]
     }' \
     https://api.fiberax.com/v1/servers

The answer comes back before the server is ready:

{
  "data": { "id": 10871, "name": "web-01", "status": "creating", ... },
  "task": { "id": "8f3c...", "status": "pending", "is_terminal": false,
            "poll": "/v1/tasks/8f3c..." }
}

You already have the identifier - use it. The Idempotency-Key above matters: if the connection drops and you repeat the call with the same key, you get the same server back instead of a second one you did not want.

A refusal is remembered under that key too, for a day. So if the request was wrong and you fix it, send a NEW key: repeating with the old one returns the stored refusal, and a changed body under the old key is rejected outright as idempotency_key_reused (422).

6. Wait for it

curl -H "Authorization: Bearer $FBX_TOKEN" \
     https://api.fiberax.com/v1/tasks/8f3c...

Poll until is_terminal is true. Then read the server itself - the task tells you the work finished, the resource tells you what it finished as.

7. Describe it with Terraform or OpenTofu

Everything above is also available as a Terraform provider, fiberax/fiberax: servers, SSH keys, public addresses, private networks, disks, network cards, the server firewall and backup policies, plus data sources for server types, images and prices.

The provider is in a trial period and is not in the public registry yet. It is served from our own mirror, and Terraform installs it from there once you tell it where to look. Put this into ~/.terraformrc (on Windows: %APPDATA%\terraform.rc):

provider_installation {
  network_mirror {
    url     = "https://docs.fiberax.com/terraform/mirror/"
    include = ["registry.terraform.io/fiberax/*"]
  }
  direct {
    exclude = ["registry.terraform.io/fiberax/*"]
  }
}

For OpenTofu the file is ~/.tofurc and the registry name is its own:

provider_installation {
  network_mirror {
    url     = "https://docs.fiberax.com/terraform/mirror/"
    include = ["registry.opentofu.org/fiberax/*"]
  }
  direct {
    exclude = ["registry.opentofu.org/fiberax/*"]
  }
}

Three things about these lines. The trailing slash in url is required: without it Terraform does not complain about the file, it says the provider "was not found in any of the search locations", as if it did not exist. include keeps the mirror to our provider only; without it every other provider you use would be looked for on our mirror as well. The exclude under direct is optional, but with it a mirror outage is reported as "not found" instead of a confusing message from the public registry.

Then reference the provider as usual. The token is the same one as above; the provider reads it from FIBERAX_TOKEN if you leave token out:

terraform {
  required_providers {
    fiberax = {
      source  = "fiberax/fiberax"
      version = "0.3.0"
    }
  }
}

provider "fiberax" {}

resource "fiberax_server" "web" {
  name           = "web-01"
  server_type_id = 4
  image          = "fcf9f69c8630904c1d6d73a821f4e674"
  cores          = 2
  memory_mb      = 4096
  disk_gb        = 40
  ssh_keys       = [13]

  public_ipv4 = { new = true }
}

terraform init should end with Installed fiberax/fiberax v0.3.0 (verified checksum). It will also print a yellow warning, Incomplete lock file information for providers: that is how Terraform behaves with any provider that does not come from the registry, not a fault of the mirror. It matters only when the lock file is shared between machines with different operating systems - then record every platform you use once:

terraform providers lock -net-mirror=https://docs.fiberax.com/terraform/mirror/ \
    -platform=linux_amd64 -platform=darwin_arm64 -platform=windows_amd64

When the provider reaches the public registry, you delete the provider_installation block and change nothing else: the source address in your configuration is already the final one. Every resource and data source, with its fields, examples and import syntax, is in the provider reference. Tell us about anything that behaves differently from what you expected - that is what the trial is for.

8. Where to go next

• The reference - every operation, with the fields each one accepts.
• Error codes - what each refusal means and what to do about it.
• The OpenAPI document - feed it to a generator to get a client library.

Two habits worth forming early

Send an idempotency key on everything that creates or charges. Servers and public addresses cost money; a retry without a key can buy you two of them.

Branch on code, not on text. The title of an error is written for a human and may be reworded. The code is part of the contract.

Something here not matching what you see? Quote the X-Request-Id of the call when you write to us - it is how we find it.