Developers

Build on ProjectX — keys, SDKs, a CLI and signed webhooks.

Everything a ProjectX integration needs, in one place: a generated API reference, SDKs for TypeScript and Python, a command line for scripts and CI, API keys you create in the console, and webhooks that are signed, retried and replay-protected with a delivery log you can read. Sign up free, add credits when you build, and work against the real API from the first call.

Start free Read the API reference

API reference

The reference is generated from the OpenAPI documents in the repository, so it cannot describe a route that does not exist or miss one that does. Each operation names the permission the decision point is asked about, so you can see which grant a call needs before you write it.

Read the API reference

SDKs

Two clients, generated from the same manifest, with no runtime dependencies so neither can conflict with what your application already pins. Both retry safely with an idempotency key on every mutating call, page over cursors, poll long-running operations, and keep the whole problem document on an error. They also ship the webhook signature verification, so you verify a delivery with the same code we sign it with.

TypeScript — @projectx/sdk

Install the package, construct a client with a token, and make a first call. Builds for the browser and for Node from one source.

TypeScript

npm install @projectx/sdk

import { ProjectXClient } from '@projectx/sdk';

const projectx = new ProjectXClient({
  credentials: { kind: 'token', token: process.env.PROJECTX_TOKEN! },
  baseUrl: 'https://api.acme.projectx.dev',
});

const order = await projectx.cloud.vps.create({ name: 'web-1', spec: { sku: 'px.c2.small', region: 'eu-central', image: 'ubuntu-24.04' } });
const settled = await projectx.waitForOperation(order.operation);

Python — projectx_sdk

The mirror of the TypeScript client, in Python conventions. No runtime dependencies — it uses the standard library, not a pinned HTTP package.

Python

pip install projectx_sdk

from projectx_sdk import ProjectXClient

projectx = ProjectXClient(
    credentials={"kind": "token", "token": os.environ["PROJECTX_TOKEN"]},
    base_url="https://api.acme.projectx.dev",
)

order = projectx.cloud.vps.create({"name": "web-1", "spec": {"sku": "px.c2.small", "region": "eu-central", "image": "ubuntu-24.04"}})
settled = projectx.wait_for_operation(order["operation"])

Both SDKs ship the webhook signature check, so a receiver verifies a delivery with the same code that signed it — the freshness window and the constant-time comparison are handled for you rather than left as a footnote.

Command line

prx is one command per API operation, because the command tree is the operation manifest rather than a copy of it. It reads its configuration from the environment, so there is nothing to mount into a CI container, and its exit codes are branchable so a script does not have to parse stderr.

Configured from the environment.: PROJECTX_TOKEN and PROJECTX_ENDPOINT point it at a deployment; PROJECTX_TENANT and PROJECTX_PRINCIPAL point it at a local dev stack. Every one has a flag that overrides it.
Discoverable.: Run prx for the services, add --help at any level to drill from a service to a noun to a verb, and the leaf prints the route, the permission and the arguments.
--wait follows the operation.: A command that starts long-running work can wait for it to finish and exit non-zero if it failed, so a pipeline step that provisioned nothing does not report success.
Scriptable output.: --jsonl prints one object per line for jq and xargs, --yes skips the are-you-sure on a change, and the exit code says what happened: 0 fine, 3 denied by policy, 4 not found, 7 the platform did not answer.

bash

export PROJECTX_TOKEN=...
export PROJECTX_ENDPOINT=https://api.acme.projectx.dev

prx cloud vps list --jsonl
prx cloud vps create --body '{"name":"web-1","spec":{"sku":"px.c2.small","region":"eu-central","image":"ubuntu-24.04"}}' --wait

The prx command line

API keys

A company creates its own API keys in the console, scoped to exactly the permissions a call needs. The secret is shown once, at creation, and never again — copy it then. A key a script or a CI job uses is an API key issued in your company, with the same hashing, rotation grace window and usage tracking as everything else.

Create API keys in the console

Webhooks

Subscribe an endpoint to event types and ProjectX delivers a signed POST when one fires. Deliveries are signed with a rotating secret, carry a stable event id so a receiver can deduplicate, and are retried with backoff. A receiver that rejects an old timestamp is safe from replay, which is why the signature covers the timestamp. The console shows a delivery log — what was sent, whether it landed, and a replay for one that did not.

Signed.: Each delivery carries an HMAC over the timestamp and body. The SDKs ship the verification, so you check it the way we sign it.
Retried, then parked.: A delivery that does not land is retried with backoff for about a day; an endpoint that keeps failing is auto-disabled so a dead receiver is not a queue that grows without bound.
Replay-protected, and replayable.: The stable event id lets a receiver be exactly-once over at-least-once delivery, and the console can replay a failed delivery byte-for-byte so a receiver sees the event it missed.

The webhook delivery log

Sandbox

There is no separate test plane, and this page will not pretend there is one. A new company adds a first deposit — and earns the first-deposit bonus on it — then builds against the real API from the first call — the same endpoints, the same keys, the same webhooks production uses.

A small first deposit, and a bonus on top.: Signing up is free. Your first deposit earns bonus credits to experiment with, and you build against the live API and draw the balance down as you go.
Nothing to pay up front.: There is nothing to pay until you add a card or exceed the grant, so you can take the SDKs and the CLI for a full run before any invoice.
One environment, honestly.: Because there is no isolated test plane, what you build on your first credits is what runs in production — no second set of keys, no behaviour that only exists in a sandbox.

Ready to build?

Create a company, add your first credits, and issue your first key in the console. The reference, the SDKs and the CLI are all one call away.

Start free Read the API reference