I'm getting familiar with the API and having trouble understanding the pattern used to name fields.

A call like CRM.api3('Address', 'get') makes sense to me because the fields in the result are (1) named consistently, and (2) each named exactly as they appear in MySQL. I see things like street_address, location_type_id, and is_primary. I like this.

A call like CRM.api3('Activity', 'get') produces fields which make slightly less sense. I see subject and status_id which seem consistent. Good. But then I see activity_date_time and activity_type_id and become confused about why some fields are named with their entity as a prefix and some are not... But at the very least, all these field names are consistent with the column names in MySQL. Ok fine, I can live with that.

But then when I look at the same call for Contribution, I get even more confused. I see fields like contribution_check_number which seem to have an added prefix, not present from MySQL. Why?

And when I look at Participant, all the fields have a participant_ prefix. Huh??

Is there some sort of underlying pattern that can explain this madness to my logic-seeking brain?


1 Answer 1


For historical reasons (namely cramming a bunch of fields from various entities into a flat array for e.g. a profile form) some fields in the database have a "unique_name" which is generally the entity prefixing the field name. For obscure reasons, the api v3 sometimes returns those "unique_names" instead of the regular field names.

I personally hate the implementation of unique names in CiviCRM - it's inconsistent and confusing and if I have anything to say about it there will be no unique names in api v4!

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.