Unable to exchange Authorization Code + PKCE for user token / unable to send chat messages

[luiscyphre404-cmd]

Unable to exchange Authorization Code + PKCE for user token / unable to send chat messages

Hello Kick Dev Team,

I am developing a custom application for my own Kick channel.

What works

Using grant_type=client_credentials, I can successfully obtain an app token.

Token introspection returns:

{
  "active": true,
  "token_type": "app"
}

With this token I can successfully:

• Create event subscriptions
• Receive webhook events
• Receive chat.message.sent events

What does not work

Sending messages through:

POST /public/v1/chat

returns:

401 Unauthorized

when using the app token.

Authorization Code + PKCE

I generated a valid:

• code_verifier
• code_challenge (S256)

The authorization endpoint successfully returns an authorization code.

However, exchanging the authorization code for a user token fails.

Tests performed:

• client_id + client_secret in request body → 401
• Basic Authentication → 400

The same credentials successfully work with:

grant_type=client_credentials

Questions

1. Can POST /public/v1/chat be used with an app token obtained via client_credentials?
2. If not, what exact OAuth flow is required?
3. Is Authorization Code + PKCE currently supported for chat message publishing?
4. Which scopes are required?
5. Could you provide a working example of the token exchange request?
6. Does sending chat messages require additional approval or bot-specific credentials?

Thank you.
Luis

[zachisfine]

Not a maintainer, but a couple of things worth checking:

1. POST /public/v1/chat with an app token: App tokens (client_credentials) generally cannot send chat as a user — sending as a user requires a user access token from the Authorization Code + PKCE flow. The endpoint accepts a type field which controls this: type: "bot" sends as your bot identity (works with app token in some setups), type: "user" sends as the authenticated user and requires broadcaster_user_id in the body plus a user token. The request shape is:

POST https://api.kick.com/public/v1/chat
Authorization: Bearer <token>
Content-Type: application/json

{ "content": "...", "type": "user", "broadcaster_user_id": 12345 }

If you're getting 401 with an app token and type: "user", that's expected — switch to either type: "bot" or a user token.

2. PKCE token exchange failing: The token endpoint expects application/x-www-form-urlencoded (not JSON) and the body must include all of: grant_type=authorization_code, code, client_id, client_secret, redirect_uri (byte-identical to the one used in /oauth/authorize), and code_verifier. Common causes of your symptoms:

• 400 with Basic Auth: missing redirect_uri or code_verifier in the body — both are still required even when credentials are in the header.
• 401 with creds in body: client_id/client_secret mismatch, or the authorization code was already consumed / expired (codes are single-use and short-lived — re-run the authorize step for each test).

See https://docs.kick.com/getting-started/generating-tokens-oauth2-flow and the scopes list at https://docs.kick.com/getting-started/scopes for the exact scope name your app needs requested at authorize time.

[luiscyphre404-cmd]

Hello zachisfine!

I wanted to share the outcome of my Kick chat integration testing.

After a lot of trial and error, I was able to successfully send chat messages through the Kick API.

Key finding:

Using an OAuth2 Client Credentials token was sufficient for:

• Event subscriptions
• Webhook events
• Reading chat events

However, it was NOT sufficient for sending chat messages. Every attempt to post messages with a Client Credentials token resulted in 401 Unauthorized responses.

The solution was to implement the OAuth2 Authorization Code flow with PKCE and obtain a user access token instead.

Working setup:

• OAuth2 Authorization Code + PKCE
• User Access Token
• POST /public/v1/chat
• Authorization: Bearer <user_access_token>

Once a valid user token was used, chat messages were sent successfully.

Additional notes:

• Access tokens and refresh tokens can be stored and reused.
• The integration survives service restarts when the tokens are persisted.
• Event subscriptions continue to work with the application token, while chat posting requires the user token.

The issue that ultimately pointed me in the right direction was the discussion around user tokens versus application tokens for chat posting.

Hopefully this helps anyone else who is getting 401 responses while trying to send chat messages with a Client Credentials token.

Thanks a lot.

Luis