iFormBuilder API

Table of Contents

• API Versions
• Versions
• Changelog

API Versions

Starting in 8.0, we rebuilt how our API code is formatted.  This means we are able to build a new version quicker and more efficiently.

Versions

• v8.1 Original Release July 2021: Documentation - Changelog
• v8.0 Original Release May 2021: Documentation - Changelog
• v6.0 Original Release July 2015: Documentation

Changelog

v8.0 -> v8.1

• GET List Endpoints Parameter:  all_fields and exclude
  • all_fields: With all endpoints that return a list (ex. /pages or options/) the default response is just a list of IDs.  If you add all_fields=1(ex. /pages?all_fields=1), it will return all the data for each object.
  • exclude: In addition to all_fields, we also have added exclude.  This can be used on list endpoints (in tandem with all_fields=1) or endpoints with specific IDs.  For example, if you do a list of records and all_fields=1, it might make the request slow or maybe not return at all because of the size of the data.  Using exclude allows you to exclude the fields, such as subform data, so you don't need to make the response smaller and quicker.  This can be applied to any data except for ID.
• GET Records

Our GET records have a huge update.  In the past, our meta data and user collected data have been together in the JSON as shown in the example below:

{
    "id": 170,
    "parent_record_id": 0,
    "my_collected_data": "Collected Data"
}

In 8.1, we separated the meta data collected data to look like this:

{
	"metadata": {
		"id": "29",
		"parent_record_id": "0"
         }
         "data": {
                 "my_collected_data": "Collected Data"
}

With the format change, we added new parameters that can be added:

• • javascript_state: By default, javascript_state will be returned but if added with the parameter and set to 0, it will no longer show.
  • all_fields: As mentioned above, we added the all_fields parameter to a GET List endpoints.  When doing a default GET records request, it will only return the IDs.  If you set all_fields=1, it will return all the data on the parent level.
  • is_deep: By default when you use all_fields=1, the subform data will show the record IDs but not the actual data.  By using all_fields=1&is_deep=1 together, it will return all the subform data as well.
  • meta_data: By default, this is set to 1.  If set to 0, it will remove all the meta data except for ID.
  • element_metadata: When setting element_metadata to 1, in addition to the value and column name of the element, it will also display the label and element_id.

• New Endpoint for Assigned User Groups to a User
  • We added "profile/###/users/###/user_groups" endpoint as a GET.  This will return an array of the user groups the user is assigned to. See below for example:

    [{
    "user_group_id": 290820226,
    "user_group_name": "User Group 1"
    },
    {
    "user_group_id": 290820227,
    "user_group_name": "User Group 2"
    
    }]

v6.0 -> v8.0

• Performance Increase

Between versions 6.0 and 8.0, the response time of calls has decreased by 50%.  

• Create Records Error Feedback

In 6.0, when creating a record and two fields cause the call to fail, the response would only show one field at a time.  In 8.0, if multiple fields cause the call to fail, it will list each one with the error message.  The error message would look like something like this:

[{
   "error_message": "Invalid key_value for element picklist_1"
},{
   "error_message": "Invalid key_value for element picklist_2"
},{
   "error_message": "Invalid element name for 'invalid_element'"
}
]

• GET Page

The 'permissions' object has new fields added to GET Page request: shared, shared-subform and shared-lookup.  Shared means it is a form that is being shared to another profile.  Shared-subform means it is shared to another profile as a subform of a parent form that is being shared. Shared-lookup means that form is being used as a lookup table for a form that is being shared to another profile.

• POST and PUT HTTP Callbacks

When adding an error_email or notification_email HTTP callbacks, it has to be either blank or a valid email.  In 6.0, any string worked which had caused problems.

• Partial Success

When making a call that contains multiple objects and has a mix of failures and/or successes, we now respond with 207 instead of 400.  For example, when using our records endpoint to create multiple records, there could be cases where some succeed and some fail. If all succeed, it will return a 200 and if all fail it will return a 400.

• Status Code for Tigger Post

Since triggering a post for a record is asynchronous,  we now return 202 to let you know the request has been accepted and will process. 

You can also import the API 8.0 collection into POSTman to get started quickly. Download the file below and then use it to import into POSTman.