Create interactions
The Interactions Endpoint URL for the Discord app.
POST /v1/provider/discord/interactions
| Address | https://api.hanzo.ai/v1/provider/discord/interactions |
| Method | POST |
| Operation | post_provider_discord_interactions |
| Auth | Authorization: Bearer $HANZO_API_KEY |
The Interactions Endpoint URL for the Discord app. It answers Discord's PING with a PONG, and handles the /hanzo slash command by acknowledging with a deferred ephemeral reply and editing that reply with the answer once the agent has run. Any other interaction is acknowledged and ignored.
Requests are verified by ED25519 SIGNATURE over the timestamp and body against the app's public key — not by HMAC, unlike the Slack webhooks. Interactions work over plain HTTP, so no gateway connection and no message-content intent is involved.
Discord does not retry, so this is the one channel where being at capacity is shown to the user as an ephemeral ask-to-run-it-again rather than answered as a retriable failure — nothing is recorded either way, so the next attempt is clean.
The caller here is the PLATFORM, not a Hanzo tenant, so there is no bearer and no principal. The signature check IS the authentication, and it fails closed. The tenant is never read from the payload either: it is resolved from the verified platform identifier through the connection map, so an event from a workspace nobody connected does nothing. Refusals are written with their own status rather than being flattened to a 500, so a rejected signature reads as 401 and a malformed body as 400.
Request
The document declares no body for POST /v1/provider/discord/interactions. The handler is typed in cloud but its shape is not yet emitted, so the fields are not listed here — ask MCP's describe for post_provider_discord_interactions, which answers from the running route.
Response
The document declares no response body for this operation. It answers 200 on success and the platform error shape on failure — see Errors.
Examples
hanzo provider discord interactionsimport { Configuration, ProviderApi } from 'hanzoai';
const api = new ProviderApi(new Configuration({ accessToken: process.env.HANZO_API_KEY }));
const { data } = await api.postProviderDiscordInteractions();from hanzoai.cloud import ApiClient, Configuration
from hanzoai.cloud.api import ProviderApi
client = ApiClient(Configuration(access_token=os.environ["HANZO_API_KEY"]))
result = ProviderApi(client).post_provider_discord_interactions()cfg := hanzoai.NewConfiguration()
cfg.AddDefaultHeader("Authorization", "Bearer "+os.Getenv("HANZO_API_KEY"))
client := hanzoai.NewAPIClient(cfg)
resp, _, err := client.ProviderAPI.PostProviderDiscordInteractions(context.Background()).Execute()
if err != nil {
return err
}use hanzo_client::apis::{configuration::Configuration, provider_api};
let mut cfg = Configuration::new();
cfg.bearer_access_token = std::env::var("HANZO_API_KEY").ok();
let result = provider_api::post_provider_discord_interactions(&cfg, Default::default()).await?;import ai.hanzo.cloud.ApiClient;
import ai.hanzo.cloud.api.ProviderApi;
ApiClient client = new ApiClient();
client.setBearerToken(System.getenv("HANZO_API_KEY"));
var result = new ProviderApi(client).postProviderDiscordInteractions();The method above is the one at the current release of the document. [email protected] (npm) was 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/provider/discord/interactions \
-H "Authorization: Bearer $HANZO_API_KEY"MCP declares no tool for provider — tools/list on https://api.hanzo.ai/v1/mcp names the products it does reach. Use HTTP or an SDK.
How is this guide?