I have tested your API endpoint and identified the issue.
The 401 authentication error occurs because your OAuth 1.0a signature calculation does not include all query parameters. When you add paging[current_page]=1 to your request, this parameter must be included in the signature base string. The signature must account for every parameter in your request URL, including all paging and sorting parameters. Parameters must be sorted alphabetically and URL-encoded properly before generating the signature.
I recommend switching to Basic Authentication instead. This approach is simpler and eliminates the signature complexity. Your API supports Basic Authentication over SSL. You just need to send your consumer key and secret with each request.
Here is a working example using Basic Authentication that I tested on your site. This request successfully returns the latest entries first without any authentication errors:
GET /wp-json/gf/v2/forms/{id}/entries?paging[page_size]=10&paging[current_page]=1&sorting[key]=id&sorting[direction]=DESC
Authorization: Basic {base64 encoded consumer_key:consumer_secret}
The sorting parameters with direction=DESC will return the newest entries first, which resolves your original concern about not getting the latest entries.
If you prefer to keep using OAuth 1.0a, ensure your signature calculation includes every query parameter in the request. The Gravity Forms REST API documentation shows the correct format for parameter encoding and signature generation.
Thank you very much. Basic authentication works now, but I have a new question. I’m missing the newest entry. When I use Postman, I get all the entries. When I call it in code, the newest entry is missing, and I only get it later—sometimes hours later. Can I change anything to get all the entries? This might be important for users.
Thanks for the update. I’m glad Basic Authentication is working.
Since Postman shows all entries immediately but your code does not, this suggests your HTTP client might be caching responses. To fix this, add cache control headers to your requests to explicitly tell the client not to cache anything. Set the “Cache-Control” header to “no-cache, no-store, must-revalidate” and add a “Pragma” header with “no-cache.”
As a quick test to confirm this is a caching issue, try adding a timestamp parameter to your URL, like ?cache=1737184123456. This makes each request unique and bypasses any caching. If the newest entry appears immediately after doing this, you’ll know caching is the culprit, and you can implement proper cache headers instead of using the timestamp workaround.
If the issue persists after adding these headers, check if you are behind a corporate proxy or firewall that might be caching requests. Let me know if the timestamp test works.