Documentation

Build on Webyne AI Cloud

The console and the API are the same surface. Anything you can click, you can call — with the same authorisation, metering and audit behind it.

Quickstart

Sign in to the console, open Settings → API keys and create a key. It is shown once. Then ask the gateway for a plan:

curl -X POST https://cloudai.webyne.com/api/v1/chat/completions \
  -H "authorization: Bearer wby_..." \
  -H "content-type: application/json" \
  -d '{
    "model": "webyne-max",
    "stream": false,
    "messages": [
      {"role": "user", "content": "Build a CRM with Next.js, Node.js and PostgreSQL on Kubernetes"}
    ]
  }'

The reply contains an architecture, a data model, an API surface, a repository scaffold and a priced infrastructure plan. Turn it into a real project:

# 1. create the project
curl -X POST https://cloudai.webyne.com/api/v1/projects \
  -H "authorization: Bearer wby_..." -H "content-type: application/json" \
  -H "idempotency-key: $(uuidgen)" \
  -d '{"name":"Acme CRM","description":"CRM for the sales team"}'

# 2. dispatch the supervisor
curl -X POST https://cloudai.webyne.com/api/v1/projects/$PROJECT/agent-runs \
  -H "authorization: Bearer wby_..." -H "content-type: application/json" \
  -H "idempotency-key: $(uuidgen)" \
  -d '{"goal":"Build a CRM with Next.js, Node.js and PostgreSQL on Kubernetes"}'

# 3. watch it work
curl https://cloudai.webyne.com/api/v1/agent-runs/$RUN \
  -H "authorization: Bearer wby_..."

Authentication

Machine calls use a bearer API key scoped to one tenant. Browser sessions use an HttpOnly cookie issued after password and TOTP verification. Both resolve to the same principal, and every request is bound to a tenant before it touches data.

  • Keys are stored hashed; the plaintext is returned only at creation.
  • Revoking a key takes effect immediately.
  • Production deployments additionally require an operator role and satisfied MFA.
  • Critical actions require step-up re-authentication within the last ten minutes.

Chat completions

The endpoint is OpenAI-compatible, so existing clients work. Request a model alias — webyne-fast, webyne-pro, webyne-max,webyne-code — and the router picks the version, handles health and fails over to a Webyne-hosted model if an external provider is unavailable. Streaming responses are server-sent events; the first frame reports which model actually served the request.

data: {"object":"chat.completion.route","model":"webyne-max","provider":"webyne","privacy":"local"}
data: {"object":"chat.completion.chunk","choices":[{"delta":{"content":"## Plan"}}]}
...
data: {"choices":[{"finish_reason":"stop"}],"usage":{"prompt_tokens":13,"completion_tokens":648},"ttft_ms":14}
data: [DONE]

Projects & agents

A project owns its repository, environments, builds, deployments and resources. An agent run is a checkpointed state machine: every step is written before the next one starts, so a run is resumable and fully auditable. Steps record the tool that was used and the risk the policy engine assigned to it.

Infrastructure

The lifecycle is deliberate and cannot be short-circuited:

request → architecture plan → price estimate → IaC diff → policy check
       → approval → apply → health check → inventory → monitor

POST /v1/infrastructure/plans returns desired state, a monthly estimate and an OpenTofu diff, and provisions nothing. apply returns 409until the plan has been approved.

Deployments

Preview and staging deploy on request. Production returns 428 together with the policy decision unless the call carries approved: true from a principal that holds the role and has satisfied MFA. Every deployment keeps a rollback reference.

API reference

MethodPathDescription
POST/v1/chat/completionsOpenAI-compatible completion. Set stream:true for SSE.
GET/v1/modelsModel aliases available to your tenant, with prices and context windows.
GET/v1/projectsList projects.
POST/v1/projectsCreate a project and bootstrap its repository.
GET/v1/projects/{id}Project with files, commits, builds, deployments and resources.
GET/v1/projects/{id}/filesList generated files, or read one with ?path=.
POST/v1/projects/{id}/agent-runsDispatch the supervisor against a goal.
GET/v1/agent-runs/{id}Run state and every checkpointed step.
POST/v1/buildsRun the build pipeline for a commit.
POST/v1/deploymentsDeploy to preview, staging or production.
GET/v1/deploymentsDeployment history.
POST/v1/infrastructure/plansTurn a request into desired state, a price and an IaC diff.
POST/v1/infrastructure/plans/{id}/approveApprove a plan.
POST/v1/infrastructure/plans/{id}/applyApply an approved plan.
GET/v1/resourcesInventory, filterable by ?category=.
GET/v1/metricsPlatform or resource telemetry.
GET/v1/logsLog entries, filterable by level and trace id.
POST/v1/remediations/{id}/approveApprove and execute a proposed remediation.
GET/v1/usageMetered consumption and recurring spend.
GET/v1/audit-eventsThe audit trail.
GET/v1/api-keysManage machine credentials.

Conventions

Idempotency

Every mutation accepts an Idempotency-Key header. Replaying a key returns the stored response instead of performing the action twice — safe for retries and at-least-once queues.

Tracing

Every response carries X-Trace-Id. The same id appears on the agent run, the build, the deployment, the log lines and the audit events, so one identifier connects a support question to the work that caused it.

Errors

{"error": {"message": "plan must be approved before apply", "status": 409, "detail": null}}

401 unauthenticated · 403 role or step-up missing ·409 wrong state · 422 invalid body · 428 approval required, with the policy decision attached.

Ready to try it?

Request access, or sign in if you already have an account.