Skip to main content

Limits and quotas

An account is bounded both by how many resources it may hold and by the compute its VMs may consume in total. The API returns those bounds together with current usage, so a client can show what is left and warn the user before sending a request instead of after a refusal.

What GET /limits returns

The response is a set of quotas. Each one carries three numbers: limit — how many you may have, used — how many are in use now, and remaining — how many you may still create. remaining is never negative.

  • projects, accessTokens, networks, publicIps — per-user counts.

  • vmResources — cpu, ram and disk summed across all of your VMs. Units are cores, gigabytes and gigabytes.

  • maxSshKeysPerProject — a plain number rather than a quota: the cap applies inside one project, so usage depends on which project you are looking at.

curl --request GET \
  --url 'https://api.zennohosting.com/v1/limits' \
  --header 'Authorization: Bearer <token>' \
  --header 'Accept: application/json'

Usage is a snapshot, not a promise

used reflects the moment of the request and may be slightly stale. It is meant for display and pre-checks. The authoritative decision happens when the resource is created, so a request can still be rejected right after remaining looked positive. Treat limits as a hint for the UI, not as a replacement for error handling.

What GET /limits/name-lengths returns

These are validation rules rather than quotas: the maximum lengths of values a user supplies. They are the same for everyone and do not change per request, so the response carries no usage — only the caps.

  • maxProjectNameLength, maxNetworkNameLength, maxVmNameLength — project, network and VM names.

  • maxSshKeyNameLength and maxSshKeyPublicKeyLength — the key's name and the public key value itself.

  • maxAccessTokenNameLength — the access token name.

Fetch these once at client start-up and validate input before sending a request: the API enforces the same caps and rejects anything longer.

curl --request GET \
  --url 'https://api.zennohosting.com/v1/limits/name-lengths' \
  --header 'Authorization: Bearer <token>' \
  --header 'Accept: application/json'

Three different kinds of limit

Do not conflate account quotas with the two other kinds of bound. They live in different parts of the API and behave differently.

  • Account quota — how much you are allowed. See GET /limits.

  • Capacity availability — whether the cluster can host a given configuration right now. See availability and maxCount in the configurations list. This one is the platform's bound, not yours: when it runs out, VM creation answers 409 Conflict with code insufficientCapacity.

  • Validation rules — name and key lengths. See GET /limits/name-lengths.

  1. 1

    Fetch limits when the user signs in

    One call to GET /limits covers every "x of y used" indicator: projects, networks, public IPs, tokens and compute.

  2. 2

    Cache name lengths, not usage

    The GET /limits/name-lengths response is stable and can be fetched once per session. Usage from GET /limits changes with your resources, so refresh it after creating and deleting them.

  3. 3

    Validate before sending

    If remaining is zero, do not send the create request — tell the user the quota is exhausted. If a name is too long, show the error in the form.

  4. 4

    Still handle the refusal

    A client-side check does not remove the need to handle the response: state can change between reading limits and creating the resource, including from another session of the same user.

GET/limits

Read the user's quotas together with current usage.

GET/limits/name-lengths

Read the maximum name and public key lengths.

GET/configurations

Check whether capacity exists for a configuration.

GET/projects/{projectId}

Read a project's resourceCounts: VMs, networks, public IPs.