Pulling Custom Fields

Interacting with OpenApply's API with custom fields

Use Case

Integrations that use OpenApply's powerful custom fields feature benefit from understanding how these fields are presented in the Public API.

Custom field interfaces in the public API

Please find the table below for an at-a-glance reference:

API interface	Usage
Get all Students Get a Student endpoints	Fetch custom fields values from within the custom_fields object
Get Students' Searchable Attributes Get Parents' Searchable Attributes	Fetch the available custom fields, including type.
fields parameter in Get all Students fields parameter in Get a Student	Learn how to fetch only the fields needed, instead of all of them: Using Field Mask

Attributes on the Student Model

There are student attributes that accessible from the root object of the student model (the response to "Get a Student" and "Get all Students"). These are (in alphabetical order):

address,address_ii,admitted_date,applicant_id,applied_at,applied_date,birth_date,campus,campus_id,checklist_state,city,contact_date,country,custom_id,declined_date,email,enrolled_at,enrolled_date,enrollment_date,enrollment_grade,enrollment_year,first_name,full_address,gender,grade,graduated_date,id,inquired_at,inquired_date,last_name,latest_activity_date,managebac_student_id,mb_id,name,nationality,other_name,passport_id,postal_code,preferred_name,profile_photo,profile_photo_updated_at,representative,serial_number,sibling_ids,source_campaign,state,status,status_changed_at,status_level,student_id,tags,updated_at,wait_listed_date,withdrawn_date

Explanations for these fields can be found in the Student model

Attributes outside of the Student Model

When it comes to custom fields, the first thing to understand is that custom fields do not belong to a form. While the UI presents custom fields from the context of certain forms, in the API, they are shown nested inside custom_fields of the student or parent model, since they are actually associated to users. Some custom fields are created by default, or by the support team during the implementation phase, or by admissions officials. In OpenApply, user-created custom fields can belong to students or parents as above, and there are two different categories. There can be "plain" custom fields that have a string value, or they can be a "container" (which we call a grouped field) that contains a set of plain custom fields, also having string values. Some grouped fields are created by default in every OpenApply instance, for example vaccinations and school history, both of which belong to students.

Custom fields in the API response

The student model includes these custom fields in the custom_fields block of a student record. Each key within it is the slug (similar to "Short Name" on the UI) that represents the field. If it is a plain custom field, its value will be a string. If it is container, instead it will be an array of records, where each record is a plain field. The endpoints Get Student Searchable Attributes & Parent Searchable Attributes responds with data records that expose all of those described above. It divides the custom fields into sections, student_slug, form_slug, supplementary_slug, and questionnaire_slug. (It also has tag_slug for all the tags that OA has, but these aren't really custom fields so ignored here.) OpenApply-maintained:

• The student_slug includes fields that can be passed to "Search Students by Attributes" to find student records that match a value. (It is not a complete set of the attributes above, as we don't support searching by all of them.)

• The supplementary_slug contains custom fields that are created by default in OpenApply. They are retrievable from the respective user model, in the custom_fields block.

• The questionnaire_slug contains custom fields that belong to forms (created by OpenApply and not users). These cannot be fetched from the API.

User-maintained:

• The form_slug contains user-created custom fields that belong to users. The slug property can be found in the custom_fields block. These can be retrieved from the respective user model.