Looking for advice on Message History API pagination failures in high-volume Digital flows

General Discussion
1

Looking for advice on handling inconsistent pagination behavior when retrieving message history for large-scale Digital conversations via the Platform API. Our AppFoundry integration serves as the primary CRM bridge for several enterprise clients, and we are encountering a specific bottleneck during the initial synchronization phase.

  • The integration utilizes the GET /api/v2/conversations/messaging/{conversationId}/messages endpoint to fetch historical context for agents joining active chats.
  • We are observing a scenario where the next_page_token returned in the response headers becomes invalid or returns an empty array after approximately 150-200 messages, despite the conversation containing over 1,000 exchanges.
  • This issue appears intermittent but correlates strongly with conversations that have high media attachment density (images and PDFs), suggesting a potential payload size or processing timeout on the backend aggregation layer.
  • The error manifests not as a standard 4xx or 5xx response, but rather as a successful 200 OK with a truncated dataset and a stale token that yields no further results upon subsequent requests.
  • We have verified that our OAuth tokens possess the conversation:read scope and are not hitting rate limits, as the request frequency is well below the documented thresholds for our tenant tier.
  • The Architect flow involved is a standard Digital queue with no custom plugins intercepting the message history retrieval, isolating the problem to the API layer itself.
  • We are currently implementing a fallback mechanism using the Conversation API (/api/v2/conversations/{id}) to fetch metadata, but this does not provide the granular message body content required for our agent assist features.
  • Has anyone encountered similar pagination truncation issues with high-volume messaging threads, or is there a recommended alternative approach for bulk message retrieval that avoids this token invalidation? We are considering switching to event-driven webhooks for real-time updates, but the historical sync remains a critical blocker for go-live.