Answers whether one proposed spend fits inside this org's caps.

GET /v1/billing/alerts/authorize

Billing → · All API references → · Six flows, four surfaces →


Address	`https://api.hanzo.ai/v1/billing/alerts/authorize`
Method	`GET`
Operation	`get_billing_alerts_authorize`
Auth	`Authorization: Bearer $HANZO_API_KEY`

It is the per-request verdict the metering edge consumes before every priced call, and its caller is a SERVICE rather than a person: a service token plus the gateway-pinned org, with no user behind it. So this admits that principal where the CRUD beside it does not.

Every covering row is evaluated, most-restrictive-wins, and the tightest one is what capCents, spentCents and reason describe. Soft rows never deny; nor does a project-scoped enforcing row whose project axis the caller could not establish — pv=1 is how a caller states that it did, and an unproven claim must not be able to refuse traffic.

A named handler, not a closure, so zipdoc can lift this prose into the registry.

Request

4 fields.

Field	In	Type	Required	Description
`project`	query	string	—	Project narrows the verdict to one project's caps.
`service`	query	string	—	Service narrows it to one service's caps.
`amount`	query	string	—	Amount is the proposed spend in cents.
`pv`	query	string	—	PV is "1" when the caller ESTABLISHED the project rather than merely carrying a claim of one.

Response

Status	Body	Meaning
`200`	CapVerdict	ok

200 body — 5 fields.

Field	In	Type	Always
`allow`	body	boolean	—
`capCents`	body	integer	—
`reason`	body	string	—
`spentCents`	body	integer	—
`warnPct`	body	integer	—

Failure carries the platform error shape — see Errors.

Examples

hanzo billing alerts authorize

import { Configuration, BillingApi } from 'hanzoai';

const api = new BillingApi(new Configuration({ accessToken: process.env.HANZO_API_KEY }));
const { data } = await api.getBillingAlertsAuthorize();

from hanzoai.cloud import ApiClient, Configuration
from hanzoai.cloud.api import BillingApi

client = ApiClient(Configuration(access_token=os.environ["HANZO_API_KEY"]))
result = BillingApi(client).get_billing_alerts_authorize()

cfg := cloud.NewConfiguration()
cfg.AddDefaultHeader("Authorization", "Bearer "+os.Getenv("HANZO_API_KEY"))
client := cloud.NewAPIClient(cfg)

resp, _, err := client.BillingAPI.GetBillingAlertsAuthorize(context.Background()).Execute()
if err != nil {
	return err
}

use hanzo_cloud::apis::{configuration::Configuration, billing_api};

let mut cfg = Configuration::new();
cfg.bearer_access_token = std::env::var("HANZO_API_KEY").ok();

let result = billing_api::get_billing_alerts_authorize(&cfg, Default::default()).await?;

import ai.hanzo.cloud.ApiClient;
import ai.hanzo.cloud.api.BillingApi;

ApiClient client = new ApiClient();
client.setRequestInterceptor(b -> b.header("Authorization", "Bearer " + System.getenv("HANZO_API_KEY")));

var result = new BillingApi(client).getBillingAlertsAuthorize();

curl https://api.hanzo.ai/v1/billing/alerts/authorize \
  -H "Authorization: Bearer $HANZO_API_KEY"

The door reaches billing through the billing tool, which names its 9 operations with its own verbs — this one among them, under a name only the door declares. describe explains any of them:

curl -X POST https://api.hanzo.ai/v1/mcp \
  -H "Content-Type: application/json" \
  -d '{
       "jsonrpc": "2.0",
       "id": 1,
       "method": "tools/call",
       "params": {
         "name": "describe",
         "arguments": {
           "op": "get_billing_balance"
         }
       }
     }'

Billing API · All Hanzo APIs · Interactive reference

Answers whether one proposed spend fits inside this org's caps.

Request

Response

Examples

On this page