---
title: "Set organization spending limit"
method: PUT
path: "/organizations/{org_id}/billing/spending_limit"
tags: ["Organizations"]
---

# Set organization spending limit

`PUT /organizations/{org_id}/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.

## Request body

- SpendingLimitUpdateRequest
  - `spending_limit_cents` integer, required — Monthly spending cap in cents. Must be positive. To remove a previously configured limit, send a DELETE request to the spending_limit endpoint — `0` and `null` are 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`

The updated spending limit value.

- SpendingLimitResponse
  - `spending_limit_cents` integer, nullable, required — Monthly spending cap in cents. `null` indicates that no limit is currently configured.

## Other responses

- `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.

---

[API](https://skmtc.dev/neon/apis/neon-api.md) · [All operations](https://skmtc.dev/neon/apis/neon-api/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/neon/neon-api/revisions/cfde79a5c713/schema)