Pagination

Use Cursor Pagination

1. Send the first list request with a limit and without a starting_after value.
2. Process every item in the returned data array before requesting the next page.
3. Read the pagination object in the API response.
4. If has_more is false, stop the pagination loop.
5. If has_more is true, store next_cursor and send the next request with starting_after=<next_cursor>.
6. After each page is fully processed, write your progress so a scheduled sync can resume safely.
7. Use the same pagination loop for subscribers, tags, custom fields, forms, landing pages, and segments.

• Use limit to set how many records Mailrith should return in one API response.
• Use starting_after only after Mailrith returns a next_cursor from the previous page.
• Do not invent cursor values, count pages, or assume that a record's database order will never change.
• For scheduled syncs, store the last cursor after you successfully process its page so a failed job can resume cleanly.
• For one-time exports or migrations, keep requesting pages until has_more is false.

curl "https://api.mailrith.com/v1/subscribers?limit=50&starting_after=subscriber_123" \
  -H "Authorization: Bearer mrk_example_secret_key"

{
  "data": [],
  "pagination": {
    "has_more": true,
    "next_cursor": "subscriber_456"
  }
}

Apply the Same Pattern Across Resources

• subscribers are usually the largest list, so process subscriber records page by page.
• Tags, custom fields, forms, landing pages, and segments may be smaller, but the same cursor loop keeps the integration consistent.
• If a job stops after processing a page, resume from the cursor after the last fully processed page.
• If you need a fresh full sync, start again without starting_after instead of reusing an old cursor from a different run.