Get Pancake Conversations List API — Pagination, filters & syncing at scale

TL;DR: The main endpoint is GET https://pages.fm/api/public_api/v2/pages/{page_id}/conversations?page_access_token=..., returning up to 60 conversations per call. Pagination uses a cursor (last_conversation_id) — not offset. Supports filtering by type (INBOX/COMMENT), tags, post_ids, since/until, unread_first, and order_by (updated_at | inserted_at). You must use public_api/v2 — the v1 version of this endpoint is deprecated and existing code should migrate to v2.

Once you know how to receive webhooks and send messages via the Pancake API, the next step in most integration projects is reading the list of conversations to sync into a CRM, dashboard, or recurring report. This article focuses on GET /pages/{page_id}/conversations — from basics through pagination, filters, and incremental sync patterns.

If you're new to Pancake, read the overview introduction first.

1. When do you need this API?

2. Prepare your Page Access Token

All page-level APIs (this endpoint included) require a page_access_token — not a user access_token. Generate the token at Settings → Tools → Pancake API in your page's dashboard.

Detailed steps and the User vs Page token distinction are covered in the Webhook & API guide. Not repeated here.

3. Basic endpoint

GET https://pages.fm/api/public_api/v2/pages/{page_id}/conversations?page_access_token={token}

Minimal cURL example

curl -G "https://pages.fm/api/public_api/v2/pages/123456789/conversations" \
  --data-urlencode "page_access_token=YOUR_PAGE_ACCESS_TOKEN"

Sample response shape

{
  "conversations": [
    {
      "id": "conv_abc123",
      "type": "INBOX",
      "page_uid": "123456789",
      "updated_at": "2026-05-28T08:14:22Z",
      "inserted_at": "2026-05-20T03:11:05Z",
      "tags": ["tag_id_1", "tag_id_2"],
      "last_message": {
        "text": "Hi, do you still have size M in stock?",
        "sender": "customer",
        "created_at": "2026-05-28T08:14:22Z"
      },
      "participants": [
        { "name": "John Doe", "email": null, "phone": "+1234567890" }
      ]
    }
    // ... up to 60 items
  ]
}

Key fields:

• id: used as conversation_id when calling the send-message or get-messages endpoints.
• type: INBOX (direct chat), COMMENT (post comment), LIVESTREAM (livestream chat).
• updated_at: timestamp of the most recent activity in the conversation — useful for delta-sync filtering.
• tags: array of tag IDs attached to the conversation.
• last_message: snippet of the most recent message — useful for dashboard previews.

4. Pagination with last_conversation_id (cursor-based)

The API returns up to 60 conversations per request, sorted by updated_at descending (default). To fetch the next page, take the id of the last conversation in the previous response and pass it as last_conversation_id:

curl -G "https://pages.fm/api/public_api/v2/pages/123456789/conversations" \
  --data-urlencode "page_access_token=YOUR_PAGE_ACCESS_TOKEN" \
  --data-urlencode "last_conversation_id=conv_xyz_last_id_from_previous_response"

Pancake uses cursor-based pagination, not offset-based. Implications:

• No page=2 or offset=60 query parameter like traditional REST.
• Loop until the response returns an empty conversations array — that's your end-of-data signal.
• Safer than offset when data changes constantly (no skipped or duplicated rows when new conversations arrive mid-pagination).

Pseudo-code pagination loop (JavaScript)

const BASE = 'https://pages.fm/api/public_api/v2'
const PAGE_ID = process.env.PAGE_ID
const TOKEN = process.env.PAGE_ACCESS_TOKEN

async function fetchAllConversations() {
  const all = []
  let lastId = null

  while (true) {
    const params = new URLSearchParams({ page_access_token: TOKEN })
    if (lastId) params.set('last_conversation_id', lastId)

    const res = await fetch(`${BASE}/pages/${PAGE_ID}/conversations?${params}`)
    if (!res.ok) throw new Error(`HTTP ${res.status}`)

    const { conversations = [] } = await res.json()
    if (conversations.length === 0) break        // end of data

    all.push(...conversations)
    lastId = conversations[conversations.length - 1].id

    await new Promise(r => setTimeout(r, 300))   // throttle ~3 req/s, safely under the limit
  }

  return all
}

fetchAllConversations()
  .then(list => console.log(`Loaded ${list.length} conversations`))
  .catch(console.error)

5. Filtering & sorting

This is where the endpoint shines — all filters run server-side, saving bandwidth and avoiding the need to download everything client-side before filtering.

const since = Math.floor(Date.now() / 1000)       // ✓ correct — seconds
const since = Date.now()                          // ✗ wrong — milliseconds

Example 1 — Unread INBOX conversations in the last 24 hours

SINCE=$(date -u -v-24H +%s)   # macOS; on Linux use: date -u -d '24 hours ago' +%s

curl -G "https://pages.fm/api/public_api/v2/pages/$PAGE_ID/conversations" \
  --data-urlencode "page_access_token=$TOKEN" \
  --data-urlencode "type=INBOX" \
  --data-urlencode "unread_first=true" \
  --data-urlencode "since=$SINCE"

Example 2 — Filter by the "Order" tag

curl -G "https://pages.fm/api/public_api/v2/pages/$PAGE_ID/conversations" \
  --data-urlencode "page_access_token=$TOKEN" \
  --data-urlencode "tags=tag_order_id"

Example 3 — All comments on a single ad post

curl -G "https://pages.fm/api/public_api/v2/pages/$PAGE_ID/conversations" \
  --data-urlencode "page_access_token=$TOKEN" \
  --data-urlencode "type=COMMENT" \
  --data-urlencode "post_ids=ad_post_id"

6. Get messages of a specific conversation

After listing conversations, you usually need to load each conversation's messages to display or archive them. Endpoint:

GET https://pages.fm/api/public_api/v1/pages/{page_id}/conversations/{conversation_id}/messages?page_access_token={token}

Pagination uses current_count (offset-style): each request returns 30 messages prior to that index.

curl -G "https://pages.fm/api/public_api/v1/pages/$PAGE_ID/conversations/$CONV_ID/messages" \
  --data-urlencode "page_access_token=$TOKEN"

# Fetch the next 30 messages (older):
curl -G "https://pages.fm/api/public_api/v1/pages/$PAGE_ID/conversations/$CONV_ID/messages" \
  --data-urlencode "page_access_token=$TOKEN" \
  --data-urlencode "current_count=30"

The response contains a messages array where each item has from (sender info), message (text content), inserted_at, type, is_hidden, is_removed.

7. Polling vs Webhook — which one to use?

The question I get most often when consulting on Pancake integrations. Short answer: use both, but for different purposes.

8. Best practices for large-scale sync

When a page has tens of thousands of conversations, the wrong approach quickly leads to rate-limiting or duplicate data. A few principles:

Persist a cursor for incremental sync

After each sync, save the updated_at of the most recently processed conversation to your DB (last_sync_at). Next time, use since=last_sync_at to fetch only the delta — saving 90%+ requests compared to a full sync.

Throttle between requests — stay under 5 req/s

The Pancake Public API is capped at 5 requests / page / second. Sleep at least 200ms between pagination requests for safety (~5 req/s); 300-500ms is recommended for buffer. If multiple workers run in parallel against the same page, use a shared token bucket / queue — exceeding the limit gets you HTTP 429.

Retry with exponential backoff

5xx and 429 → retry 3 times with delays of 1s, 2s, 4s. Other 4xx (401, 403, 404) → fail immediately and log for debugging.

Idempotent upserts to your DB

Use the conversation id as primary key with INSERT ... ON CONFLICT UPDATE (Postgres) or REPLACE INTO (MySQL). Prevents duplicates when webhook and polling both insert.

Avoid webhook + polling race conditions

When the polling cron runs while a webhook is writing → race conditions are likely. Solution: treat Pancake's updated_at as a "version" — only update if the incoming updated_at is newer than the existing record.

9. Common errors

10. FAQ

Q: Why does list conversations use v2 while send message uses v1? A: Pancake is gradually migrating to v2 — list conversations is already on v2 with the new cursor pagination, while the message endpoints are still on v1. When building, always check the path in the official docs to avoid mixing them up.

Q: Can I fetch all conversations in a single request? A: No. The hard limit is 60 items per request. You must paginate with last_conversation_id.

Q: Can I filter by customer phone/email? A: The list conversations endpoint does not support this directly. To search by customer, use the separate GET /pages/{page_id}/page_customers API — a future article will cover it.

Q: What unit do since and until use — milliseconds or seconds? A: Seconds (Unix timestamp). If your JS code uses Date.now() (milliseconds), wrap it in Math.floor(Date.now() / 1000). This is an extremely common bug — see the warning in section 5.

Q: What is the Public API rate limit? A: 5 requests / page / second. Exceeding it returns HTTP 429. When running parallel workers against the same page, use a shared token bucket/queue so the combined rate stays under the limit.

Q: What's the difference between order_by=updated_at and inserted_at? A: updated_at = time of the last activity (new message, new tag...) — suits realtime dashboards. inserted_at = time the conversation was created — suits "new conversations this week" reports.

Q: How often should I poll? A: Every 5-10 minutes is the sweet spot for most use cases when combined with webhooks — fast enough to recover missed events, light on quota. Very small pages (under 50 conversations/day) can stretch to 30 minutes. Don't poll more often than once per minute — wasteful and unnecessary when webhooks already cover realtime.

Q: What schema should I use to sync into an internal DB? A: Minimum: id (PK), page_id, type, tags (JSONB/JSON), updated_at, inserted_at, last_message (JSONB), participants (JSONB), synced_at. Index on (page_id, updated_at) for fast delta queries.

Q: Is there anything more realtime than webhooks? A: No, and you don't need it. Webhooks are the best realtime mechanism Pancake offers. If webhooks feel delayed, your server is slow at processing — optimize on your side (queue, async), not Pancake's.

11. Summary

• Main endpoint: GET /pages/{page_id}/conversations on public_api/v2, max 60 items per request.
• Pagination: cursor-based with last_conversation_id. No offset.
• Server-side filtering: type, tags, post_ids, since, until, unread_first, order_by.
• Production pattern: webhook + polling delta with since=last_sync_at for reconciliation.
• Best practices: throttle 500ms-1s, exponential backoff for retries, idempotent upserts by id.

Related posts & tools

• Pancake Webhook & API Send Message Guide — prerequisite post on webhooks + reply API.
• Introducing Pancake — Multi-channel Chat Management Platform — high-level overview.
• Tool: Get Page ID from a Facebook link — convert a fanpage URL into the page_id you need for API calls.
• Pancake Developer Docs — official documentation (OpenAPI spec).

Last updated: 2026-05-28. API versions: public_api/v2 for list conversations, public_api/v1 for messages. Any changes will be updated in this post.