Refuse answers a request by declining it, recording who declined and why.
Refuse answers a request by declining it, recording who declined and why. Nothing is released and no link is minted.
POST /v1/dataroom/trust/requests/{id}/refuse
| Address | https://api.hanzo.ai/v1/dataroom/trust/requests/{id}/refuse |
| Method | POST |
| Operation | post_dataroom_trust_requests_by_id_refuse |
| Auth | Authorization: Bearer $HANZO_API_KEY |
Refuse answers a request by declining it, recording who declined and why.
Nothing is released and no link is minted. The refusal STAYS on the record beside the ask — a request that was turned down is part of the access record exactly as one that was granted is, and deleting it would leave a queue that only ever shows the decisions somebody liked.
A request that was already answered is refused rather than answered twice. Only an admin of the org may call it, and the request is resolved in that org's own store, so another org's request id is not found.
Request
4 fields, body application/json (required).
| Field | In | Type | Required | Description |
|---|---|---|---|---|
id | path | string | yes | ID is the request to answer, taken from the path. |
days | body | integer | — | Days is how long the grant stays open, from now. |
id | body | string | — | ID is the request to answer, taken from the path. |
note | body | string | — | Note is why. |
Response
| Status | Body | Meaning |
|---|---|---|
200 | trustRefused | ok |
200 body — 1 field.
| Field | In | Type | Always | Description |
|---|---|---|---|---|
state | body | string | — | State is "refused". |
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, DataroomApi } from 'hanzoai';
const api = new DataroomApi(new Configuration({ accessToken: process.env.HANZO_API_KEY }));
const { data } = await api.postDataroomTrustRequestsByIdRefuse({ id: 'id', days: 0, id: "<id>" });from hanzoai.cloud import ApiClient, Configuration
from hanzoai.cloud.api import DataroomApi
client = ApiClient(Configuration(access_token=os.environ["HANZO_API_KEY"]))
result = DataroomApi(client).post_dataroom_trust_requests_by_id_refuse(id='id', days=0, id="<id>")cfg := cloud.NewConfiguration()
cfg.AddDefaultHeader("Authorization", "Bearer "+os.Getenv("HANZO_API_KEY"))
client := cloud.NewAPIClient(cfg)
resp, _, err := client.DataroomAPI.PostDataroomTrustRequestsByIdRefuse(context.Background()).Execute()
if err != nil {
return err
}use hanzo_cloud::apis::{configuration::Configuration, dataroom_api};
let mut cfg = Configuration::new();
cfg.bearer_access_token = std::env::var("HANZO_API_KEY").ok();
let result = dataroom_api::post_dataroom_trust_requests_by_id_refuse(&cfg, Default::default()).await?;import ai.hanzo.cloud.ApiClient;
import ai.hanzo.cloud.api.DataroomApi;
ApiClient client = new ApiClient();
client.setRequestInterceptor(b -> b.header("Authorization", "Bearer " + System.getenv("HANZO_API_KEY")));
var result = new DataroomApi(client).postDataroomTrustRequestsByIdRefuse();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/dataroom/trust/requests/<id>/refuse \
-H "Authorization: Bearer $HANZO_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"days": 0,
"id": "<id>"
}'The door reaches dataroom through the dataroom tool, which names its 17 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_dataroom_analytic_dataroom"
}
}
}'How is this guide?