Skip to main content
Answered

Discrepancy in Pagination Format for /companies/list Endpoint

  • March 28, 2025
  • 1 reply
  • 44 views

Hi, I am currently using the OpenAPI specification provided in your YAML file to generate an API client for the /companies/list endpoint. According to the YAML, pagination is implemented via a "pages" object, which includes a "next" property defined as a starting_after_paging object. This object is expected to contain properties like per_page and starting_after.

However, the actual API response returns the "next" property as a plain URL string, for example:

"pages": {
  "type": "pages",
  "next": "https://api.intercom.io/companies/list?page=2&per_page=1&order=desc",
  "page": 1,
  "per_page": 1,
  "total_pages": 223
},
"total_count": 223

I have verified that this behavior is consistent even when using the API testing tool provided at https://developers.intercom.com/docs/references/rest-api/api.intercom.io/companies/listallcompanies

Could you please clarify whether this is a known issue or an intentional change in the API implementation that has not yet been reflected in the YAML documentation? Any guidance on how to proceed—whether through an updated specification or a recommended workaround—would be greatly appreciated.

Thank you for your assistance.

Best answer by Paul B12

Hi ​@Podpora 

You're absolutely right, the OpenAPI YAML specifies next as an object containing starting_after_paging, the actual API response returns next as a full URL string. This suggests that the docs may be outdated or misaligned with the current API behavior.

For now, the best approach would be to use the next URL directly for pagination rather than relying on starting_after. If your API was built assuming the object format, you might need to adjust the parsing logic to accommodate the URL format instead.

View original
Did this topic help you find an answer to your question?

Paul Byrne
Intercom Team
Forum|alt.badge.img+2
  • Intercom Team
  • March 30, 2025

Hi ​@Podpora 

You're absolutely right, the OpenAPI YAML specifies next as an object containing starting_after_paging, the actual API response returns next as a full URL string. This suggests that the docs may be outdated or misaligned with the current API behavior.

For now, the best approach would be to use the next URL directly for pagination rather than relying on starting_after. If your API was built assuming the object format, you might need to adjust the parsing logic to accommodate the URL format instead.


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings