2

I have the CiviCRM API REST interface working fine for retrieving Case information for individual cases. But I'd like to use the options features options.limit and options.offset so I can retrieve data page by page from CiviCRM in response to a search. But whatever I try, nothing seems to alter the limit and the offset numbers of the retrieved records. Only the first 25 records are returned, ie the default number. Has anyone else had a similar problem?

The json payload looks like this:

json={
"return":"id,custom_116,custom_16",
"custom_116":{"IS NOT NULL":1},
"options":{"limit":100,"offset":100}
}

This is the REST format suggested by the API explorer (v3).

Am I doing something wrong? The search criterion ("IS NOT NULL") is ignored as above, but searches works correctly when not in object format, eg "custom_116":"StringToSearch". The limit and offset parameters are also ignored. So it seems likely that the problem is to do with the object format for these parameters. Any ideas? Or is there an alternative way of formatting the query json? Thanks.

CiviCRM 5.9.0 Joomla 3.9.1 php 7.0.31

  • Regarding IS NOT NULL, the field could also technically be the empty string, so not null would be true. Testing on the public demo seems to confirm this. – Demerit Jan 13 '19 at 22:48
  • 1
    The limit parameter seems to work for me on a local 5.9.0 install in the object format you have above / as suggested by the api explorer, e.g. http://path/to/rest.php?entity=Case&action=get&api_key=my_api_key&key=my_site_key&json={"sequential":1,"return":"id,custom_1","custom_1":{"IS NOT NULL":1},"options":{"limit":1}} Also the IS NOT NULL comment above seems to hold on my local install - if I use "<>":"" instead then it works to exclude blank ones. My install is drupal - I doubt that would make a difference for this though. – Demerit Jan 13 '19 at 23:42
  • Thanks. This doesn't work for me, but I found an answer, posted separately. – Jern Jan 27 '19 at 14:12
  • This ^^ was the answer for me regarding civicrm apiv3 get contacts limit. This is why I wish people would quit documenting so heavily in proprietary languages like php that do weird stuff to your payload. If you're writing docs for an http api and if you're going to write it in multiple languages anyway, please for the love of god make one of them the HTTP payload. I'm using Talend. Thank you Jern. – Jason Miller Nov 29 '19 at 19:53
  • The API Explorer is the primary documentation (Support menu > Developer > API Explorer) and generates REST examples for anything you throw at it. – Jon G - Megaphone Tech Nov 30 '19 at 20:15
2

In the end, I was only able to make it work by using array notation. Some examples below. All these worked in the array notation on the right, but not in the object notation on the left:

"options": {"limit":"100","offset":"100"}  --->  "options[limit]": "1","options[offset]": "100"

"custom_1": {"IS NOT NULL":"1"}  --->  "custom_1[IS NOT NULL]": "1"

"custom_1": {"LIKE": "%stringtosearch%}  --->  "custom_1[LIKE]":"%stringtosearch%"

So in my case my json payload looked like this:

json = {
      "return": "id,custom_116,custom_16",
      "custom_16[IS NOT NULL]": "1",
      "custom_15[<>]": "",
      "options[limit]": "50",
      "options[offset]": "50",
      "options[sort]": "id"
    }

Next task is to work out how to convert the OR option into array notation:

"options":{"or":[["custom_15","custom_16"]]}  ---> ???

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.