when writing extensions, i often try to keep the code compatible with several versions of civi instead of having to maintain different branches.

however, i sometimes would like to use a new feature if it's available, for instance, civi 4.6 introduced an option to force rollback that i would like to use, but if i'm using this option and run the code with civi 4.5, it will silently ignore it and won't rollback.

is there a way from the api to test the version that is running, or -my preference- if a specific feature is implemented?

2 Answers 2


As Coleman suggests, one can do more direct inspections to see if particular entities/actions/fields are supported. This is generally more robust/correct in the long-run, but it can be problematic in some edge-cases. There is a way to get the version number.

In CiviCRM v4.4+, use the System.get API, e.g.

drush cvapi system.get
    [is_error] => 0
    [version] => 3
    [count] => 1
    [id] => 0
    [values] => Array
            [0] => Array
                    [version] => 4.4.17
                    [uf] => Drupal


Of course, checking an API is mildly expensive. If you need to guard many statements with version checks, then it could add up. To mitigate this:

  • If using the API remotely to inspect system state, cache the data for a few minutes.
  • If writing server-side PHP code, don't use an API. Instead, call CRM_Utils_System::version() and version_compare().

At a most levels, yes you can query the api for certain features. For example:

civicrm_api3('Entity', 'get');

will tell you all available entities.

civicrm_api3('Contact', 'getactions');

will tell you all available actions for e.g. the Contact entity.

civicrm_api3('Contact', 'getfields', array('action' => 'create'));

will tell you all available fields for e.g. the Contact::create action.

civicrm_api3('Contact', 'getoptions', array('field' => 'prefix_id'));

will tell you available options for a certain field, e.g. the Contact individual_prefix.

However, your question is about specific option to be passed into the "options" array, which unfortunately is completely undocumented as far as api metadata goes. I'd love for this shortcoming to be addressed, particularly because the api explorer is suffering because of it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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