Rest API gravity forms, cURL

I have a problème with the Rest API of gravity forms, I use it with the cURL method, I have no problem with, except with the size of the J-son chain, he only give me 10 last entry to the concerned forms, if anyone know how to ask more entry (or all the entries of the form, that would be perfect but some forms have more than 1000 entry, i think it’s to heavy for the j-son link) thanks in advance for you’r help and I wish you a good afternoon, Joseph.

Welcome @joseph_menard-lansac!

A couple of questions.

  1. Gravity forms is a product or service using the JSON.api specification?
  2. Can you use curl to source the --data from a file, reducing the complexity of the command? See below.

From curl manual, see -d, --data <data>

If you start the data with the letter @, the rest should be a file name
to read the data from, or - if you want curl to read the data from
stdin. Multiple files can also be specified. Posting data from a file
named from a file like that, carriage returns and newlines will be
stripped out. If you don't want the @ character to have a special
interpretation use --data-raw instead.

Edit I think your question relates to Gravity Forms pagination API on a second read. See GET /entries here and page_size. But 1000 may be a process intensive request, so tread lightly. If this was about POSTing 1000 forms, see above and reference the Gravity Forms API documentation.

But this forum is really not for generic JSON API discussions. See below.


@joseph_menard-lansac The Gravity Forms REST API v2 is “a JSON API”, but it does not follow the json:api specification. This discussion forum is for the json:api specification specifically, not for generic JSON API implementations or questions.

This often causes confusion in web searches, but please see Section 2, Introduction for what the JSON.api specification is, and why Gravity Forms does not conform to the specification.

Though I hope my previous answer provides you a way of managing your request data size.


Another demonstration of naming being the hardest problem in software engineering.



1 Like

@fdrake We had a “homebrew,” as in :beer:, slack channel at my previous employer. We would often get random questions about “homebrew,” the Mac OS *nix package manager, in the channel from colleagues, completely out of context to the conversation taking place about bottle shares, specific gravities, recipes, and flamewars about extract, partial, and full-grain brewing. :laughing: It happens.

1 Like

The proper solution to such inappropriate questions would have been to take the Mac OS devices away from the questioners.

Of course, my position on Mac OS might present as bias.