# KickTokenGen.com — AI assistant guide

Human guide: https://kicktokengen.com/ai
API reference: https://kicktokengen.com/docs
OpenAPI: https://kicktokengen.com/docs/openapi.json

Choose a flow your actual tools and policies permit BEFORE creating a workflow.
Ask which tool is being configured, which account should authorize, which operations
it needs, and whether its own issuing application is required. Never request a Kick
password. Use official Kick API scopes, not Twitch names or IRC assumptions.

For sending chat, chat:write is sufficient. Receiving chat and events requires a
webhook on the developer application. This site does not relay events. A shared-app
token does not configure the user's bot endpoint. Stream keys are sensitive.

Full HTTP clients:
1. GET /api/v2/scopes to select permission IDs or canonical scope names.
2. POST /api/v2/workflows with {"title":"Tool name","scope_ids":[6],"is_ai":true,
   "ai_agent":"Your actual client name"}. When shared mode is unavailable, use the
   manual generator, or securely supply an optional credentials object containing
   the user's own client_id and client_secret in the POST body.
3. Keep retrieval_key private. Give the human only authorization_url.
4. After the human returns, GET status_url with Authorization: Bearer <retrieval_key>.
   202 means pending; wait at least five seconds. 200 returns credentials ONCE.
   410 means denied, expired or already consumed. Retain the entire successful
   response only when your environment permits handling credentials. Never claim
   possession before a successful response. Workflows expire after 24 hours.

Permitted fetch-only clients:
GET /api/v2/ai/workflows/create?scope_ids=6&title=Tool&ai_agent=Client
This requires enabled shared mode and returns authorization_url and retrieval_url.
The retrieval URL contains a bearer capability. Treat it as a password: never cite,
search for, log or publish it. Retrieve only if your tool policy permits private
capability URLs and credential responses. Tokens and client secrets are never URL
parameters. A successful private fetch consumes the stored token pair once.

Claude web-fetch and any client that cannot retrieve private credentials must use
manual guidance from the start. Public fetching does not establish private access.
Do not encode URLs or weaken security to bypass a tool restriction. No email is
needed for automatic AI workflows. Email Token Requests are a separate feature.

Manual fallback:
Send a preselected public link, for example
https://kicktokengen.com/?welcome=0&scope=chat%3Awrite
The human enters their own app credentials if needed, authorizes the correct Kick
account, and copies the result directly into their tool. Do not ask them to paste
secrets into chat. A token belongs to its issuing application and is not generally
interchangeable with a token under another developer's client ID.

Tools use POST /api/v2/tokens/validate, /refresh and /revoke with JSON bodies.
Refresh needs the issuing app's client_id and client_secret, or the enabled shared
refresh service. Preserve replacement refresh tokens and returned expiry values.
Only request permissions needed for the user's task; do not add user:read solely
for site statistics. Never promise that a token alone creates a working chat bot.