Endpoint: /v1/deals/:id/mailMessages?include_body=1&start=&limit=
I have 3 emails for a particular deal, ids: 15,16,17
Problem: The start parameter is incorrectly skipping records during pagination, causing data loss.
Test Setup
-
Deal ID: 81 (only an example)
-
Total emails: 3 (IDs: 15, 16, 17)
-
Expected order: [17, 16, 15] (newest to oldest)
Reproduction Steps
Test the API with different start and limit combinations:
| start | limit | Expected Result | Actual Result | Status |
|---|---|---|---|---|
| 0 | 3 | [17, 16, 15] | [17, 16, 15] |  Correct |
| 0 | 2 | [17, 16] | [17, 16] | Correct |
| 0 | 1 | [17] | [17] | Correct |
| 1 | 3 | [16, 15] | [15] |  Missing ID 16 |
| 1 | 2 | [16, 15] | [15] | Missing ID 16 |
| 1 | 1 | [16] | Missing ID 16 |
|
| 2 | 1 | [15] | Missing ID 15 |
Expected Behavior
Standard offset-based pagination:
-
start=0→ Begin at position 0 -
start=1→ Begin at position 1 (skip 1 record) -
start=2→ Begin at position 2 (skip 2 records)
Actual Behavior
-
start=0works correctly -
start=1incorrectly skips to position 2, missing the record at position 1 -
start=2returns empty results instead of the last record
Impact
This bug makes it impossible to reliably paginate through deal emails, causing data loss in integrations that rely on pagination to process all records.
Please let me know if you need any additional details or if there are specific API documentation references that clarify the expected pagination behavior.