> ## Documentation Index > Fetch the complete documentation index at: https://docs.wppfy.com/llms.txt > Use this file to discover all available pages before exploring further. # Request on-demand history for a chat > Requests from WhatsApp an on-demand sync of older messages from a chat, going backward from a reference message (anchor). To recover a saved message that failed to open (`messageType: "error"` in `/message/find`), use `POST /message/reload`. Rules: - send `number` - `count` is optional and limited to 100 - `messageid` is optional; when provided, the API uses that message as the reference to fetch older messages from the chat Note: - **Important:** recovery may only happen after opening WhatsApp on the phone or keeping it active in the background - `messageid` defines the reference message for loading earlier history; this field does not fetch that specific message - if you want to recover only a specific message `X` via history, provide as `messageid` the message right after `X` and use `count=1` - if `messageid` is not provided, the API uses the oldest locally known message of that chat as the reference to fetch earlier history - messages are returned later via webhook/SSE in `history` type events and are also available in `/message/find` ## Result The response contains the request's `request_id`. Messages arrive in the `history` webhook/SSE with `event: "messages"` and the `request_id` in each message. It also appears at the top of `messages` and `chats` batches when the entire batch belongs to the same request; mixed batches may omit it at the top. The request ends with a single `event: "status"` batch with the same `request_id`: - `status`: `completed` when WhatsApp confirms the request's completion, `timeout` when there was no conclusive response within 2 minutes, `blocked` when the phone indicates more messages but did not deliver a page that advances - `success` and `error`: only when there is no possible next page; `success: false` and the reason in `error` (`pagination_no_progress`, `anchor_unavailable`, `history_access_unavailable` or `cursor_lookup_failed`). Always come with `blocked` - `has_more`: what the phone declared. `true` there are more messages on the phone, `false` the beginning of the conversation was reached, `null` not confirmed. Some devices declare `true` in every on-demand response, including empty ones: with them, pagination ends in `blocked` with `pagination_no_progress`, never in `has_more: false` - `history_access`: `unavailable` when there are more messages but WhatsApp does not grant access to them - `next_request`: ready-made body to request the earlier messages; resend it as received. `null` when there is no usable next request To paginate, resend `next_request` from the final result until it comes back `null`, waiting for the result of each request. `completed` ends the request, not the whole conversation. `next_request: null` without `has_more: false` does not prove the beginning of the conversation. Silence or a batch with fewer messages than `count` does not indicate the end of the history: only `has_more: false` does. With `blocked` and `error: "pagination_no_progress"`, stop paginating that chat without automatically repeating the request: it is the end of what the phone delivers from that anchor, and repeating gives the same result. Each chat has one active request at a time. Repeating the request with the same reference message before the `status` returns the same `request_id` (`details.reused: true`), without a new send to the phone. A request with a different reference ends the previous one, which receives its own final `status` (usually `timeout`), and proceeds normally. `409` only occurs when the provided `requestId` is already in use. The final result arrives via webhook/SSE within 2 minutes after sending the request to WhatsApp (`details.result_timeout_ms`). Late messages may keep arriving with the same `request_id` for about 5 minutes after the request, without a second final status. ## Synchronous mode (`sync: true`) `sync: true` holds the response until the result, for up to `timeoutMs` (default and maximum 25000). Messages come in `messages`, and the top of the response contains the same fields as the final `status` (`status`, `has_more`, `history_access`, `received_messages`, `next_request`), plus `received`, `timed_out` and `partial`: - final result within the deadline: `200` with that result; - messages arrived, but not the result: `200` with `status: "pending"`, about 2 seconds after the last message; - nothing arrived within the deadline: `202` with `status: "pending"`, `timed_out: true` and empty `messages`. With `status: "pending"`, the final result arrives later via the `history` webhook/SSE, with the same `request_id`. The webhook and SSE are also sent in synchronous mode, and messages are saved the same way. ## Deleted reference message If the anchor was deleted, the API tries to use the next valid message of that chat. `details.requested_anchor_messageid` reports the requested reference, `details.anchor_messageid` the one used, and `details.anchor_replaced` indicates the substitution. With no alternative, it returns HTTP `400` with `status: "anchor_unavailable"`; try without `messageid` to use the oldest saved message. ## OpenAPI ````yaml /openapi-en.json post /message/history-sync openapi: 3.1.0 info: title: WppFy - WhatsApp API version: 1.0.0 description: > API for managing WhatsApp instances and communications. ## Important Recommendation: WhatsApp Business **It is HIGHLY RECOMMENDED to use WhatsApp Business accounts** instead of regular WhatsApp for integration; regular WhatsApp may present inconsistencies, disconnections, limitations, and instability when used with our API. ## Authentication - Regular endpoints require a 'token' header with the instance token ## Instance States Instances can be in the following states: - `disconnected`: Disconnected from WhatsApp - `connecting`: Connection in progress - `connected`: Successfully connected and authenticated servers: - url: https://api.wppfy.com security: - token: [] tags: - name: Instance description: | Operations related to an instance's lifecycle, such as connecting, disconnecting, and checking status. - name: Proxy description: > WppFy uses an internal proxy by default. You can keep this default, configure your own proxy via `proxy_url`, or use your Android phone as a proxy by installing the app from https://github.com/WppFy/silver_proxy_apk (direct APK: https://github.com/WppFy/silver_proxy_apk/raw/refs/heads/main/silver_proxy.apk). If nothing is sent, we keep using the internal proxy. IPs are Brazilian; for international clients, consider a proxy in the client's region. - name: Profile description: | Operations related to the WhatsApp instance profile, such as changing the profile name and picture. - name: Business description: | ⚠️ **EXPERIMENTAL** - Endpoints not yet fully tested. Operations related to the WhatsApp Business business profile. Allows querying and updating business profile data such as description, address, email, categories, and managing the product catalog. **Requirements:** - The currently connected account must be a **WhatsApp Business** account - Personal WhatsApp accounts do not have a business profile **Note:** These endpoints may not work as expected. Report any problems found. - name: Calls description: | Operations related to WhatsApp calls. Allows making and rejecting calls programmatically. - name: Send Message description: > Endpoints for sending WhatsApp messages with different content types. ## Common Optional Fields All message sending endpoints support the following optional fields: - **`delay`** *(integer)*: Delay in milliseconds before sending - During the delay, "Typing..." or "Recording audio..." will appear depending on the type - Example: `5000` (5 seconds) - **`readchat`** *(boolean)*: Mark chat as read after sending - Removes the unread message counter from the chat - Example: `true` - **`readmessages`** *(boolean)*: Mark last received messages as read - Marks the last 10 **received** messages (not sent by you) as read - Useful to confirm reading pending messages before replying - Different from `readchat` which only removes the unread counter - Example: `true` - **`replyid`** *(string)*: ID of the message to reply to - Creates a reply linked to the original message - Support varies by message type - Example: `"3A12345678901234567890123456789012"` - **`mentions`** *(string)*: Numbers to mention (only for group sending) - Specific numbers: `"5511999999999,5511888888888"` - Mention all: `"all"` - **`forward`** *(boolean)*: Marks the message as forwarded in WhatsApp - Adds the "Forwarded" indicator to the message - Example: `true` - **`track_source`** *(string)*: Message tracking source - Identifies the system or source sending the message - Useful for integrations (e.g., "chatwoot", "crm", "chatbot") - Example: `"chatwoot"` - **`track_id`** *(string)*: ID for message tracking - Free identifier to track the message in external systems - Allows correlating messages between different platforms - **Note**: The system accepts duplicate values - there is no uniqueness validation - Use the same ID in multiple messages if it makes sense for your integration - Example: `"msg_123456789"` ### Sending to Groups - **`number`** *(string)*: To send a message to a group, use the group ID ending with `@g.us` - Example: `"120363012345678901@g.us"` - **How to get the Group ID:** - Use the `chatid` from the webhook received when someone sends a message in the group - Use the `GET /group/list` endpoint to list all groups and their IDs ## Available Placeholders All message sending endpoints support dynamic placeholders for automatic personalization: ### Name Fields - **`{{name}}`**: Consolidated chat name, using the first available option: 1. Lead name (`lead_name`) 2. Lead full name (`lead_fullName`) 3. WhatsApp contact name (`wa_contactName`) 4. WhatsApp profile name (`wa_name`) - **`{{first_name}}`**: First valid word of the consolidated name (minimum 2 characters) ### WhatsApp Fields - **`{{wa_name}}`**: WhatsApp profile name - **`{{wa_contactName}}`**: Contact name as saved in WhatsApp ### Lead Fields - **`{{lead_name}}`**: Lead name - **`{{lead_fullName}}`**: Lead full name - **`{{lead_personalid}}`**: Personal ID (SSN, CPF, CNPJ, etc) - **`{{lead_email}}`**: Lead email - **`{{lead_status}}`**: Current lead status - **`{{lead_notes}}`**: Lead notes - **`{{lead_assignedAttendant_id}}`**: ID of the assigned attendant ### Custom Fields Fields added via custom fields are accessible using `{{lead_field01}}` to `{{lead_field20}}` or use `{{fieldname}}` defined in `/instance/updateFieldsMap`. ### Usage Example ``` Hello {{name}}! I saw you work at {{company}}. Is your email {{lead_email}} correct? ``` **πŸ’‘ Tip**: Use `/chat/find` to fetch chat data and see available fields before sending messages with placeholders. - name: Async Message description: > Operational controls for the internal asynchronous send queue used when a send endpoint receives `async=true`. This section is used to: - check the current state of the async queue - configure the delay between messages sent with `async=true` - clear pending backlog and cancel messages not yet completed Scope: - covers only the internal queue of async direct messages - does not change messages already sent successfully - name: Message Actions and Search - name: Chats - name: Contacts - name: Blocklist - name: Labels - name: Groups and Communities - name: Newsletters and Channels description: > Operations for reading and following WhatsApp channels (newsletters). Main use cases: - list posts already published in a channel - edit recent posts in a channel - delete recent posts in a channel - check post views and reactions - integrate channels without needing to persist messages locally Notes: - `/newsletter/messages` returns the post content - `/newsletter/messages/edit` edits the content of recent posts - `/newsletter/messages/delete` deletes recent posts - views (`viewsCount`) and reactions (`reactionCounts`) come in each post of `/newsletter/messages`, not via webhook event - `/newsletter/updates` is deprecated: WhatsApp does not respond and the API returns 504 - newsletters use their own routes and must not use `/message/edit` or `/message/delete` - name: Quick Replies description: > Management of quick replies to streamline service. **⚠️ Important**: This feature is only useful if you use a custom frontend/interface to register and use the replies. The API only stores the replies, but does not apply them automatically. ### How it works: - **Create**: Register pre-defined responses with titles and content - **List**: Retrieve all registered responses to display in your interface - **Use**: Your frontend system can use these responses to speed up typing ### Use cases: - Custom web service interfaces - Mobile apps with reply suggestions - CRM systems with message templates - Productivity tools for attendants **Not a chatbot**: For automatic responses, use Chatbot features. - name: CRM description: > Complete customer relationship management system integrated with the API. **πŸ’Ύ Internal Storage**: All lead data is saved directly in the API, eliminating the need for external databases. Your application can focus only on the interface and business logic. ### Available Features: - **πŸ“‹ 20+ customizable fields**: Name, phone, email, company, notes, etc. - **🏷️ Label System**: Organize and categorize your contacts - **πŸ” Advanced Search**: Filter by any field or label - **πŸ“Š Complete History**: All interactions are registered automatically ### 🎯 Placeholders in messages: Use dynamic variables in messages for automatic personalization: ``` Hello {{name}}! I saw you work at {{company}}. Is your email {{email}} correct? Notes: {{notes}} ``` ### Typical Flow: 1. **Capture**: Leads arrive via WhatsApp or forms 2. **Enrichment**: Add data using `/chat/editLead` 3. **Segmentation**: Organize with labels 4. **Communication**: Send personalized messages with placeholders 5. **Follow-up**: History is saved automatically **Ideal for**: Sales, marketing, support, lead qualification - name: Chatwoot Integration description: > **🚧 BETA INTEGRATION - Chatwoot integration system for unified service** **⚠️ WARNING**: This integration is in BETA phase. Use at your own risk. We recommend testing in a non-production environment before use in production. This category contains resources to configure and manage integration with Chatwoot, an open-source customer service platform. The integration allows centralizing WhatsApp conversations in Chatwoot. ### Available Features: - πŸ”§ **Complete Configuration**: Configure URL, tokens, and Chatwoot credentials - πŸ“¬ **Bidirectional Sync**: New messages between WhatsApp and Chatwoot are synced automatically - πŸ“± **Contact Management**: Automatic sync of names and phones - πŸ”„ **LIDβ†’PN Update**: Automatic migration from Local ID to Phone Number - 🏷️ **Smart Names**: Name system with tilde (~) for automatic update - 🚫 **Group Separation**: Option to ignore groups in sync - πŸ‘€ **Message Signature**: Agent identification in sent messages - πŸ”— **Automatic Webhook**: URL generated automatically to configure in Chatwoot ### 🏷️ Smart Name System: - **Names with tilde (~)**: Updated automatically when contact modifies name in WhatsApp - **Specific names**: For fixed name, remove tilde (~) from name in Chatwoot - **Example**: "~John Doe" = automatic, "John Doe" = fixed - **LIDβ†’PN Migration**: No conversation duplication during transition - **Native responses**: Appear directly in Chatwoot without external markings ### ⚠️ Known Limitations: - **History sync**: Not implemented - only new messages are synced ### Use Cases: - Centralized service in Chatwoot - Support teams with multiple agents - CRM integration via Chatwoot - Communication channel centralization - Automatic contact and name management **Ideal for**: Companies with service teams, call centers, technical support (in test environment) **Requires**: Configured Chatwoot instance, API tokens, and test environment **🚧 Remember**: BETA integration - features may change without prior notice - name: Server-Sent Events (SSE) paths: /message/history-sync: post: tags: - Message Actions and Search summary: Request on-demand history for a chat description: > Requests from WhatsApp an on-demand sync of older messages from a chat, going backward from a reference message (anchor). To recover a saved message that failed to open (`messageType: "error"` in `/message/find`), use `POST /message/reload`. Rules: - send `number` - `count` is optional and limited to 100 - `messageid` is optional; when provided, the API uses that message as the reference to fetch older messages from the chat Note: - **Important:** recovery may only happen after opening WhatsApp on the phone or keeping it active in the background - `messageid` defines the reference message for loading earlier history; this field does not fetch that specific message - if you want to recover only a specific message `X` via history, provide as `messageid` the message right after `X` and use `count=1` - if `messageid` is not provided, the API uses the oldest locally known message of that chat as the reference to fetch earlier history - messages are returned later via webhook/SSE in `history` type events and are also available in `/message/find` ## Result The response contains the request's `request_id`. Messages arrive in the `history` webhook/SSE with `event: "messages"` and the `request_id` in each message. It also appears at the top of `messages` and `chats` batches when the entire batch belongs to the same request; mixed batches may omit it at the top. The request ends with a single `event: "status"` batch with the same `request_id`: - `status`: `completed` when WhatsApp confirms the request's completion, `timeout` when there was no conclusive response within 2 minutes, `blocked` when the phone indicates more messages but did not deliver a page that advances - `success` and `error`: only when there is no possible next page; `success: false` and the reason in `error` (`pagination_no_progress`, `anchor_unavailable`, `history_access_unavailable` or `cursor_lookup_failed`). Always come with `blocked` - `has_more`: what the phone declared. `true` there are more messages on the phone, `false` the beginning of the conversation was reached, `null` not confirmed. Some devices declare `true` in every on-demand response, including empty ones: with them, pagination ends in `blocked` with `pagination_no_progress`, never in `has_more: false` - `history_access`: `unavailable` when there are more messages but WhatsApp does not grant access to them - `next_request`: ready-made body to request the earlier messages; resend it as received. `null` when there is no usable next request To paginate, resend `next_request` from the final result until it comes back `null`, waiting for the result of each request. `completed` ends the request, not the whole conversation. `next_request: null` without `has_more: false` does not prove the beginning of the conversation. Silence or a batch with fewer messages than `count` does not indicate the end of the history: only `has_more: false` does. With `blocked` and `error: "pagination_no_progress"`, stop paginating that chat without automatically repeating the request: it is the end of what the phone delivers from that anchor, and repeating gives the same result. Each chat has one active request at a time. Repeating the request with the same reference message before the `status` returns the same `request_id` (`details.reused: true`), without a new send to the phone. A request with a different reference ends the previous one, which receives its own final `status` (usually `timeout`), and proceeds normally. `409` only occurs when the provided `requestId` is already in use. The final result arrives via webhook/SSE within 2 minutes after sending the request to WhatsApp (`details.result_timeout_ms`). Late messages may keep arriving with the same `request_id` for about 5 minutes after the request, without a second final status. ## Synchronous mode (`sync: true`) `sync: true` holds the response until the result, for up to `timeoutMs` (default and maximum 25000). Messages come in `messages`, and the top of the response contains the same fields as the final `status` (`status`, `has_more`, `history_access`, `received_messages`, `next_request`), plus `received`, `timed_out` and `partial`: - final result within the deadline: `200` with that result; - messages arrived, but not the result: `200` with `status: "pending"`, about 2 seconds after the last message; - nothing arrived within the deadline: `202` with `status: "pending"`, `timed_out: true` and empty `messages`. With `status: "pending"`, the final result arrives later via the `history` webhook/SSE, with the same `request_id`. The webhook and SSE are also sent in synchronous mode, and messages are saved the same way. ## Deleted reference message If the anchor was deleted, the API tries to use the next valid message of that chat. `details.requested_anchor_messageid` reports the requested reference, `details.anchor_messageid` the one used, and `details.anchor_replaced` indicates the substitution. With no alternative, it returns HTTP `400` with `status: "anchor_unavailable"`; try without `messageid` to use the oldest saved message. requestBody: required: true content: application/json: schema: type: object required: - number properties: messageid: type: string description: >- ID of the reference message used to fetch older messages from the chat. example: 3EB01234567890ABCDEF number: type: string description: Full chat JID. example: 5511999999999@s.whatsapp.net count: type: integer minimum: 1 maximum: 100 description: Desired number of messages in the sync. example: 20 default: 50 timestamp: type: integer description: >- Timestamp of the reference message, in milliseconds or seconds. Optional; it comes in `next_request` so the reference works even before the message is saved. example: 1706350400000 fromMe: type: boolean description: >- Indicates whether the reference message was sent by the connected account. Optional; comes in `next_request`. example: false requestId: type: string description: >- Optional identifier chosen by the client; when omitted, the API generates a UUID. Returned as request_id. Use a new id per request: an id already in use receives `409`. example: 5f0c2a8e-6d1b-4c3a-9e7f-1a2b3c4d5e6f fallbackMode: type: string enum: - try_alternates - exact default: try_alternates description: >- Where the request is sent. `try_alternates` (default): in an individual conversation, sends via the chat's number and LID, because the phone stores each conversation under one of the two addresses and ignores the request sent via the other; the response arrives only once. `exact`: sends only via the chat's preferred address (the LID, when known). In groups, the request always goes only to the group. sync: type: boolean default: false description: >- Holds the response until the request result, for up to `timeoutMs`. See "Synchronous mode". timeoutMs: type: integer default: 25000 maximum: 25000 description: >- Only with `sync: true`: maximum wait in milliseconds. Larger values become 25000. examples: usando_ancora_explicita: summary: Fetch history prior to a reference message value: number: 5511999999999@s.whatsapp.net messageid: 3EB01234567890ABCDEF count: 20 recuperar_mensagem_especifica: summary: Retrieve only the message immediately before the reference value: number: 5511999999999@s.whatsapp.net messageid: 3EB0MENSAGEM_LOGO_APOS_X count: 1 usando_ancora_local: summary: Reuse already persisted local anchor value: number: 5511999999999@s.whatsapp.net count: 50 proxima_pagina: summary: Request the previous messages with the received next_request value: number: 5511999999999@s.whatsapp.net count: 50 messageid: 3EB0MAIS_ANTIGA_RECEBIDA timestamp: 1706350400000 fromMe: false modo_sincrono: summary: Wait for the result in the response (synchronous mode) value: number: 5511999999999@s.whatsapp.net count: 50 sync: true timeoutMs: 20000 responses: '200': description: >- Request sent successfully. Messages and the result arrive later via webhook/SSE. With `sync: true`, it also returns the messages and the request result. content: application/json: schema: type: object properties: success: type: boolean example: true request_id: type: string description: >- Identifies the request. Appears in the correlated messages and in the final webhook/SSE history status. example: 5f0c2a8e-6d1b-4c3a-9e7f-1a2b3c4d5e6f message: type: string example: >- History sync request sent. Messages will be received as history sync events. details: type: object additionalProperties: true description: Additional operation metadata properties: result_timeout_ms: type: integer example: 120000 description: Deadline for the final result via webhook/SSE. requested_anchor_messageid: type: string description: Originally requested reference. anchor_messageid: type: string description: Reference actually used. anchor_replaced: type: boolean description: >- The deleted reference was replaced by a later valid message. reused: type: boolean description: >- The request repeats the reference of an in-progress request: the API returns its `request_id` and does not send another request to the phone. fallback_mode: type: string enum: - try_alternates - exact description: Sending mode used (`fallbackMode`). attempted_chats: type: array items: type: string description: Chat addresses to which the order was sent. sync: type: boolean description: >- `true` when the response waited for the result (`sync: true`). status: type: string enum: - completed - timeout - pending - blocked description: >- Synchronous mode only: request result; `pending` when it has not arrived yet and will come via webhook/SSE; `blocked` when the phone indicates more messages but did not deliver a page that advances (the reason comes in `error`). request_chat: type: string description: 'Synchronous mode only: chat of the request.' has_more: type: - boolean - 'null' description: >- Synchronous mode only: what the phone declared. `true` there are more messages, `false` start of the conversation, `null` not confirmed. Some devices declare `true` in every on-demand response, even an empty one: with them, pagination ends in `blocked` with `pagination_no_progress`, never in `has_more: false`. nullable: true history_access: type: string enum: - available - unavailable - unknown description: >- Synchronous mode only: `unavailable` when there are more messages without access. received_messages: type: integer description: 'Synchronous mode only: number of messages in `messages`.' next_request: type: - object - 'null' additionalProperties: true description: >- Synchronous mode only: body ready to request the previous messages, or `null`. nullable: true received: type: boolean description: >- Synchronous mode only: messages arrived or the request was completed. timed_out: type: boolean description: 'Synchronous mode only: the `timeoutMs` deadline expired.' partial: type: boolean description: >- Synchronous mode only: there may still be more messages (`has_more` other than `false`). messages: type: array items: type: object additionalProperties: true description: >- Synchronous mode only: messages of the request, in the `history` event format. error: type: string enum: - pagination_no_progress - anchor_unavailable - history_access_unavailable - cursor_lookup_failed description: >- With `status: "blocked"` (and `success: false`): why there is no `next_request`. `pagination_no_progress`: from the same anchor, the phone did not deliver a page that advances even at the largest `count` (on each page without progress, `next_request` doubles `count`, up to 100): it came back empty, without a message usable as an anchor, or repeated. This is the end of what the phone delivers from that anchor, but WhatsApp does not confirm that it is the start of the conversation; repeating the request gives the same result; `anchor_unavailable`: the reference message is no longer available, request with another one; `history_access_unavailable`: the rest is not accessible; `cursor_lookup_failed`: failed to build the next request, try again. examples: async_padrΓ£o: summary: History request sent value: success: true request_id: 5f0c2a8e-6d1b-4c3a-9e7f-1a2b3c4d5e6f message: >- History sync request sent. Messages will be received as history sync events. details: result_timeout_ms: 120000 requested_anchor_messageid: 3EB01234567890ABCDEF anchor_messageid: 3EB01234567890ABCDEF anchor_replaced: false sync_concluido: summary: Synchronous mode with result value: success: true sync: true request_id: 5f0c2a8e-6d1b-4c3a-9e7f-1a2b3c4d5e6f request_chat: 5511999999999@s.whatsapp.net status: completed has_more: true history_access: available received_messages: 1 next_request: number: 5511999999999@s.whatsapp.net count: 50 messageid: 3EB0MAIS_ANTIGA_RECEBIDA timestamp: 1706350400000 fromMe: false received: true timed_out: false partial: true messages: - messageid: 3EB0MAIS_ANTIGA_RECEBIDA chatid: 5511999999999@s.whatsapp.net fromMe: false messageTimestamp: 1706350400000 text: Mensagem antiga request_id: 5f0c2a8e-6d1b-4c3a-9e7f-1a2b3c4d5e6f '202': description: >- Only with `sync: true`: nothing arrived within `timeoutMs`. The request continues and the result arrives via the `history` webhook/SSE with the same `request_id`. content: application/json: schema: type: object properties: success: type: boolean example: true request_id: type: string description: >- Identifies the request. Appears in the correlated messages and in the final webhook/SSE history status. example: 5f0c2a8e-6d1b-4c3a-9e7f-1a2b3c4d5e6f message: type: string example: >- History sync request sent. Messages will be received as history sync events. details: type: object additionalProperties: true description: Additional operation metadata properties: result_timeout_ms: type: integer example: 120000 description: Deadline for the final result via webhook/SSE. requested_anchor_messageid: type: string description: Originally requested reference. anchor_messageid: type: string description: Reference actually used. anchor_replaced: type: boolean description: >- The deleted reference was replaced by a later valid message. reused: type: boolean description: >- The request repeats the reference of an in-progress request: the API returns its `request_id` and does not send another request to the phone. fallback_mode: type: string enum: - try_alternates - exact description: Sending mode used (`fallbackMode`). attempted_chats: type: array items: type: string description: Chat addresses to which the order was sent. sync: type: boolean description: >- `true` when the response waited for the result (`sync: true`). status: type: string enum: - completed - timeout - pending description: >- Synchronous mode only: request result; `pending` when it has not arrived yet and will come via webhook/SSE. request_chat: type: string description: 'Synchronous mode only: chat of the request.' has_more: type: - boolean - 'null' description: >- Synchronous mode only: what the phone declared. `true` there are more messages, `false` start of the conversation, `null` not confirmed. Some devices declare `true` in every on-demand response, even an empty one: with them, pagination ends in `blocked` with `pagination_no_progress`, never in `has_more: false`. nullable: true history_access: type: string enum: - available - unavailable - unknown description: >- Synchronous mode only: `unavailable` when there are more messages without access. received_messages: type: integer description: 'Synchronous mode only: number of messages in `messages`.' next_request: type: - object - 'null' additionalProperties: true description: >- Synchronous mode only: body ready to request the previous messages, or `null`. nullable: true received: type: boolean description: >- Synchronous mode only: messages arrived or the request was completed. timed_out: type: boolean description: 'Synchronous mode only: the `timeoutMs` deadline expired.' partial: type: boolean description: >- Synchronous mode only: there may still be more messages (`has_more` other than `false`). messages: type: array items: type: object additionalProperties: true description: >- Synchronous mode only: messages of the request, in the `history` event format. examples: pendente: summary: Nothing arrived in time value: success: true sync: true request_id: 5f0c2a8e-6d1b-4c3a-9e7f-1a2b3c4d5e6f request_chat: 5511999999999@s.whatsapp.net status: pending has_more: null history_access: unknown received_messages: 0 next_request: null received: false timed_out: true partial: true messages: [] message: >- History sync request sent. The final result arrives by webhook/SSE with this request_id. '400': description: >- Invalid payload, invalid mode, or insufficient anchor. `anchor_unavailable`: the reference message was deleted and there is no other usable one after it; send without `messageid` to use the oldest saved message. content: application/json: schema: type: object properties: error: type: string example: number is required success: type: boolean status: type: string enum: - anchor_unavailable request_id: type: string request_chat: type: string requested_anchor_messageid: type: string has_more: type: - boolean - 'null' nullable: true next_request: type: - object - 'null' nullable: true examples: payload_invalido: summary: Invalid payload value: error: number is required anchor_unavailable: summary: Reference message unavailable value: success: false error: anchor_unavailable status: anchor_unavailable request_id: 5f0c2a8e-6d1b-4c3a-9e7f-1a2b3c4d5e6f has_more: null next_request: null request_chat: 5511999999999@s.whatsapp.net requested_anchor_messageid: 3EB0ANCORA_APAGADA '409': description: >- The provided `requestId` is already in use by another request. Use a new id; to repeat the same request, resend it without `requestId`. content: application/json: schema: type: object properties: error: type: string example: history sync request_id already in use request_id: type: string description: Request already using this id. example: 5f0c2a8e-6d1b-4c3a-9e7f-1a2b3c4d5e6f '429': description: Limit of pending history requests on the instance. content: application/json: schema: type: object properties: error: type: string example: too many pending history sync requests '500': description: Internal error requesting the history sync content: application/json: schema: type: object properties: error: type: string example: 'Failed to request history: connection closed' '503': description: The instance is stopping; the request was not registered. content: application/json: schema: type: object properties: error: type: string example: instance is stopping components: securitySchemes: token: name: token type: apiKey in: header ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.