Document `Authorization: Bearer <token>` for existing Chatwoot API tokens, available from v4.19.0. The OpenAPI auth option explains where to obtain user, agent bot, and platform app tokens while retaining `api_access_token` as a legacy option. Follow-up to https://github.com/chatwoot/chatwoot/pull/15941. Related: https://github.com/chatwoot/chatwoot/issues/1615 and https://linear.app/chatwoot/issue/CW-2866/chore-standardise-the-access-token-based-authentication-in-chatwoot. ## Why API consumers and generated clients should be able to discover the standard Bearer header and reuse their existing tokens without changing permissions. ## What this change does - Adds HTTP Bearer as a separate authentication alternative wherever existing API tokens are accepted. - Explains that Bearer authentication is available from Chatwoot v4.19.0 and where to get user, agent bot, and platform app tokens. - Recommends Bearer auth while keeping the `api_access_token` header supported ahead of a future deprecation. - Updates the attachment request example and generated OpenAPI JSON. ## Validation Open the generated API documentation and confirm Bearer and legacy API key options appear. On a v4.19.0 instance, authorize with an existing API token and call an allowed endpoint. Confirm the attachment example uses `Authorization: Bearer`.
28 lines
621 B
YAML
28 lines
621 B
YAML
tags:
|
|
- Help Center
|
|
operationId: add-new-article-to-account
|
|
summary: Add a new article
|
|
description: Add a new article to portal
|
|
security:
|
|
- userBearerAuth: []
|
|
- userApiKey: []
|
|
requestBody:
|
|
required: true
|
|
content:
|
|
application/json:
|
|
schema:
|
|
$ref: '#/components/schemas/article_create_update_payload'
|
|
responses:
|
|
'200':
|
|
description: Success
|
|
content:
|
|
application/json:
|
|
schema:
|
|
$ref: '#/components/schemas/article'
|
|
'403':
|
|
description: Access denied
|
|
content:
|
|
application/json:
|
|
schema:
|
|
$ref: '#/components/schemas/bad_request_error'
|