Post turns products on or off for an org and returns the enabled set afterwards.
Post turns products on or off for an org and returns the enabled set afterwards.
POST /v1/entitlement/orgs/{org}
| Address | https://api.hanzo.ai/v1/entitlement/orgs/{org} |
| Method | POST |
| Operation | post_entitlement_orgs_by_org |
| Auth | Authorization: Bearer $HANZO_API_KEY |
Post turns products on or off for an org and returns the enabled set afterwards.
A product may only be ENABLED if the org's plan already ENTITLES it, so enabling never spends new money — a product the plan does not grant answers 402 and the console routes that to an upgrade prompt. DISABLING is never gated. A platform super admin bypasses the plan check (operator comp/grant) and may target any org; everyone else may only change their own. Commerce unreachable is a 503, never an implicit yes.
Request
3 fields, body application/json (required).
| Field | In | Type | Required | Description |
|---|---|---|---|---|
org | path | string | yes | |
add | body | string[] | — | Add is the product ids to turn ON. |
remove | body | string[] | — | Remove is the product ids to turn OFF. |
Response
| Status | Body | Meaning |
|---|---|---|
200 | entitlementsView | ok |
200 body — 1 field.
| Field | In | Type | Always | Description |
|---|---|---|---|---|
enabled | body | string[] | — | Enabled is the org's turned-on product ids, sorted. |
Failure carries the platform error shape — see Errors.
Examples
hanzo has no subcommand for this operation — the CLI serves only what cloud's live route table confirms. Use HTTP or an SDK.
import { Configuration, EntitlementApi } from 'hanzoai';
const api = new EntitlementApi(new Configuration({ accessToken: process.env.HANZO_API_KEY }));
const { data } = await api.postEntitlementOrgsByOrg({ org: 'org', add: ["<add>"], remove: ["<remove>"] });from hanzoai.cloud import ApiClient, Configuration
from hanzoai.cloud.api import EntitlementApi
client = ApiClient(Configuration(access_token=os.environ["HANZO_API_KEY"]))
result = EntitlementApi(client).post_entitlement_orgs_by_org(org='org', add=["<add>"], remove=["<remove>"])cfg := cloud.NewConfiguration()
cfg.AddDefaultHeader("Authorization", "Bearer "+os.Getenv("HANZO_API_KEY"))
client := cloud.NewAPIClient(cfg)
resp, _, err := client.EntitlementAPI.PostEntitlementOrgsByOrg(context.Background()).Execute()
if err != nil {
return err
}use hanzo_cloud::apis::{configuration::Configuration, entitlement_api};
let mut cfg = Configuration::new();
cfg.bearer_access_token = std::env::var("HANZO_API_KEY").ok();
let result = entitlement_api::post_entitlement_orgs_by_org(&cfg, Default::default()).await?;import ai.hanzo.cloud.ApiClient;
import ai.hanzo.cloud.api.EntitlementApi;
ApiClient client = new ApiClient();
client.setRequestInterceptor(b -> b.header("Authorization", "Bearer " + System.getenv("HANZO_API_KEY")));
var result = new EntitlementApi(client).postEntitlementOrgsByOrg();The method above is the one at the current release of the document. [email protected] (npm) and [email protected] (PyPI) were generated from an earlier release, where this operation carried a different id, so it spells the method differently — regenerating the clients is what makes the two agree. SDKs →
curl -X POST https://api.hanzo.ai/v1/entitlement/orgs/<org> \
-H "Authorization: Bearer $HANZO_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"add": [
"<add>"
],
"remove": [
"<remove>"
]
}'The door reaches entitlement through the entitlements tool, which names its 3 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": "list_entitlements"
}
}
}'How is this guide?