Set organization spending limit
API Reference / Organizations / Set organization spending limit
PUT /organizations//billing/spending_limit
Section titled “PUT /organizations//billing/spending_limit”Sets the monthly spending limit for the specified organization. To remove a previously configured limit, send a DELETE request to this endpoint. When a limit is configured, email notifications are sent at 80% and 100% of the limit. Computes are not suspended when the limit is reached. Available to organization admins on Launch and Scale plans only.
Parameters
Section titled “Parameters”org_id(string, path, required) The Neon organization ID
Request body
Section titled “Request body”spending_limit_cents(integer, required, format: int64) Monthly spending cap in cents. Must be positive. To remove a previously configured limit, send a DELETE request to the spending_limit endpoint —0andnullare rejected here. The cap is alert-only: notifications fire at 80% and 100%, but computes are not suspended. Setting a cap below the period's already-accrued spend is permitted and will trigger the over-limit notification on the next worker run.
Response (200)
Section titled “Response (200)”spending_limit_cents(integer, optional, format: int64) Monthly spending cap in cents.nullindicates that no limit is currently configured.
Code examples
Section titled “Code examples”curl "https://console.neon.tech/api/v2/organizations/$ORG_ID/billing/spending_limit" \
-X PUT \
-H "Authorization: Bearer $NEON_API_KEY"import { createNeonClient, raw } from '@neon/sdk';
const neon = createNeonClient({ apiKey: process.env.NEON_API_KEY });
const { data } = await raw.setOrganizationSpendingLimit({
client: neon.client,
path: {
org_id: process.env.ORG_ID
}
});Console
Section titled “Console”Console path: Organization → Billing → Spending limit
Errors
Section titled “Errors”default General Error.
The request may or may not be safe to retry, depending on the HTTP method, response status code, and whether a response was received.
- If no response is returned from the API, a network error or timeout likely occurred.
- In some cases, the request may have reached the server and been successfully processed, but the response failed to reach the client. As a result, retrying non-idempotent requests can lead to unintended results.
The following HTTP methods are considered non-idempotent: POST, PATCH, DELETE, and PUT. Retrying these methods is generally not safe.
The following methods are considered idempotent: GET, HEAD, and OPTIONS. Retrying these methods is safe in the event of a network error or timeout.
Any request that returns a 503 Service Unavailable response is always safe to retry.
Any request that returns a 423 Locked response is safe to retry. 423 Locked indicates that the resource is temporarily locked, for example, due to another operation in progress.
-
request_id(string, optional) Unique identifier for the request, useful for debugging. You can set this value manually by including anX-Request-IDheader in the request. If not provided, the value will be generated automatically. -
code(string, required) Machine-readable code classifying the error type. Seemessagefor a human-readable explanation. Default: `` -
message(string, required) Error message