API Access and Availability

API Access and Availability#

NexHost is operated through the dashboard. Every authenticated request your browser makes — opening a project, reading a deployment, updating environment variables, creating a domain attachment — flows through an authenticated control plane that exists to serve the dashboard itself. That control plane is a product-internal interface, not a versioned, public REST API contract for general-purpose automation.

That distinction matters for two reasons: a browser-bound interface that your workspace would automate against can change without the deprecation notices a public API must offer, and treating a browser session as a bearer token risk for a workspace expands the blast radius of credential exposure. The guidance below follows from that responsibility.

What "no public REST API" means#

• The dashboard’s own endpoints are authenticated control-plane endpoints for the dashboard. They are not published as a general-purpose public REST API contract and should not be used for unsupported automation — for example by scripting a browser session credential or by scraping and calling internal URLs observed in the network panel.
• The absence of a public API today does not mean that result tables, form endpoints, and internal request paths are stable integration surfaces. Relying on them risks breakage without warning and can expose the underlying account.

If you are evaluating whether NexHost can be automated in a pipeline, read the next section for the stable surface that does exist and the recommended path for everything else.

Supported programmatic interface#

For hosted repository workflows — the source layer that feeds the dashboard — use the Next CLI. It is the stable, supported programmatic interface for repository operations over an authenticated NexHost Git surface:

• Session and identity: next login (with --team, --device, or --pat), next logout, next whoami
• Repository lifecycle: next repo list, next repo create my-service --private
• Clone and initialization: next init, next clone YOUR_WORKSPACE/YOUR_REPOSITORY
• Source control: next status, next add ., next commit -m "…", next push, next pull, next sync
• Diagnostics: next doctor

The CLI handles repository authentication and keeps credentials out of remote URLs, so a typical workflow is:

next login --team YOUR_WORKSPACE
next repo list
next clone YOUR_WORKSPACE/YOUR_REPOSITORY
cd YOUR_REPOSITORY
# edit, test locally
next add .
next commit -m "Ship the API"
next push
# then, separately, create or reconfigure the service deployment in the dashboard

Pushing source does not by itself trigger a deployment — the dashboard is the control plane for services. The source change is the artifact the next deployment will reference, not the trigger.

Dashboard actions — the intended control plane#

Create and manage services, deployments, domains, and billing through the dashboard. Every action you need to evaluate access to — who can read a deployment log, who can rotate a secret, who can attach a custom domain — is authored there, and the set of controls your workspace sees is shown there.

The exact actions available to a workspace are the ones presented in the current dashboard and can evolve as the product matures. Treat the dashboard’s affordances as the design surface: if a workflow is absent from the dashboard and from the CLI’s documented repository operations, assume it has no supported programmatic surface yet.

Building integrations when the dashboard is not enough#

If you need an integration that cannot be completed in the dashboard or through the Git CLI — for example a custom release gate, a deployment notification that does not exist in the current UI, or a workspace-provisioning operation — contact NexHost support with the workflow you need rather than automating against browser endpoints.

What to include when you write in:

• The workspace name, which service type and source the service uses, and the step you want to perform.
• What trigger you want (every push, a filtered push, a manual gate) and who should be able to invoke it.
• Where the result should go — a channel, a deployment policy, an access change — rather than how you envision the HTTP call would look.

Support can advise on what is actually available, what is planned, and a safe integration shape that will not break silently when the dashboard evolves.

Related documentation#

• Next CLI — install, authentication modes, and the full repository workflow.
• NexHost Git — hosted repositories and the push → dashboard-connect → deploy sequence.
• Workspaces and Access — how workspace scope relates to who can perform dashboard actions.
• Deployments — the intended deployment lifecycle without leaning on unsupported endpoints.