Managani Docs

Appearance

List started widget chat conversations across every site for admins ​

Includes waiting, open, and closed chats. Returns at most 25: unread or active chats first, then closed/read chats; newest message first within each group, with updated/created time and ID fallbacks. No pagination.

Request preparation ​

Send a GET request to /product/chat/conversations on the appropriate server. Check the API overview for base URL guidance and the server information in the interactive reference. Replace path placeholders with identifiers from the intended account or site; a similarly named record in another workspace is not interchangeable.

The declared request parameters are:

  • status (query, optional): Use the type and constraints shown in the parameter reference.
  • site (query, optional): Use the type and constraints shown in the parameter reference.
  • q (query, optional): Search message text, attachment filenames, page context, notes, and customer identity. Search includes closed chats.
  • limit (query, optional): Use the type and constraints shown in the parameter reference.

No request body is declared in the current specification. Check the route and any documented parameters before sending the request rather than adding an arbitrary JSON payload.

Authentication and scope ​

The specification lists these security alternatives: BearerAuth, AccessToken. Read any operation-specific restrictions as well: browser-session, account-role, and signed-user requirements may impose additional conditions. See authentication before choosing a credential.

Keep credentials in the appropriate private configuration and remove secrets from shared logs. Confirm the target resource belongs to the intended workflow before issuing a request. Authentication alone should not be treated as confirmation that a supplied account, site, or customer identifier is correct.

Response handling ​

The documented responses for List started widget chat conversations across every site for admins are:

  • 200: OK

Begin with a known record or a narrow query and inspect the returned fields before displaying them to users. Where the operation defines pagination, follow those parameters to retrieve additional results. An empty successful response is different from a failed request; keep errors visible to the calling workflow instead of presenting them as an empty data set.

If a connection fails after submission, investigate the current server state before repeating an action whose outcome is uncertain. When requesting support, retain the method, route, response status, and sanitized error message. The interactive reference below provides the detailed schemas and examples for this specific operation.

List started widget chat conversations across every site for admins​

GET
/product/chat/conversations

Includes waiting, open, and closed chats. Returns at most 25: unread or active chats first, then closed/read chats; newest message first within each group, with updated/created time and ID fallbacks. No pagination.

Authorizations​

BearerAuth

JWT token from login

Type
HTTP (bearer)
or
AccessToken

Personal access token. Value: Token <your-token>

Type
API Key (header: Authorization)

Parameters​

Query Parameters

status
Type
string
Valid values
"all""waiting""open""closed"
site
Type
string
q

Search message text, attachment filenames, page context, notes, and customer identity. Search includes closed chats.

Type
string
limit
Type
integer
Default
25
Maximum
25

Responses​

OK

application/json
JSON
{
  
"items": [
  
],
  
"counts": {
  
}
}

Playground​

Authorization
Variables
Key
Value

Samples​

Powered by VitePress OpenAPI