The documentation suggests a typical pledge call should look like the following: GET https://www.patreon.com/api/oauth2/api/campaigns/<campaign_id>/pledges?include=patron.null. Note in particular, the include=patron.null parameter. This appears to be entirely undocumented, but including this parameter appears to have the effect of excluding non-pledge related information from the response, significantly reducing noise and data size. This is great, except that the parameter is not persisted in either the first or next pagination links.
That is, following either of the pagination links in the response drops the include=patron.null parameter, causing the response format to change. It should be considered strictly incorrect for an API to return a different data format for different pages of the same request, yet this is exactly what is happening presently.
Super sorry about this. We will add documentation about using .null to prevent following relationships.
With regards to your second point, you are completely correct that pagination should maintain the query parameters. However, for legacy reasons, doing so causes a bug in certain API requests. The fix is pending an overhaul (currently in the planning stage) to how we perform pagination in general.
Thanks, that documentation looks like it was sorely needed. Great clarification for things I had inferred and also revealing some new tricks like the explicit mode for resource inclusion.