Change Log

• 2.9
• 2.10
• 2.11

2.11

• A new API, mobility/read/csv, now returns the Mobility information as a CSV file.
• mobility/read has deprecated "with_sensor_data" in favor of a new columns parameter.
• user/read has been optimized.
• survey_response/read has a new parameter.
• survey_response/upload now accepts a new parameter called "images" to allow users to upload their images BASE64-encoded so that they don't have to create a multipart/form-post request.
• Admins may now see all information for all objects.
• Self-registration has been added along with a corresponding flag indicating whether or not it is enabled.
• Added CORS support for non-login calls.

2.10

• EasyPost is now part of the build at EasyPost.html.
• mobility/dates/read will now return all of the dates on which a user has Mobility data.
• Paging has been implemented as two parameters, one for the number of records to skip and another for the number of records in this page. There are no limits on the upper bound to preserve backwards compatibility.
• The authentication token timeout is now part of config/read.
• A flag regarding whether or not Mobility is part of the system has been added to config/read.
• The maximum allowed document size is now returned by config/read.
• mobility/read will now return the sensor data via a new parameter "with_sensor_data".
• Many performance improvements were made mainly within survey_respons/read.

2.9

• Mobility points must now contain an "id" key in their root JSONObject whose value is a valid UUID.
• The ERROR mode has been added. When the point has this mode, data may be missing or invalid. The server will still attempt to decipher as much as possible and store it.
• When uploading invalid points, that is points that couldn't be deciphered despite their mode, they will be logged on the system. Unless the entire JSONArray cannot be decoded into a JSONArray, meaning the whole data upload is invalid JSON, you will get a success message. With the success message, you will receive a new key, "accepted_ids", which will be a JSONArray of the UUIDs that were accepted. This is different than what we discussed where the server would only return the rejected values, but I felt was necessary for one important reason. What if the "id" field is the problem?
• The timestamp in the survey and mobility upload APIs (not the epoch milliseconds) will now be ignored in favor of the epoch milliseconds and timezone.
• survey/upload no longer accepts keys for the response value for custom choices nor does it expect a dictionary. Instead, the raw values should be uploaded as a single string value for single_choice_custom prompts and as a JSONArray of raw values for multi_choice_custom prompts.
• Every survey response should have a UUID in its JSONObject under the key "survey_key". This is the value that will be used in all other APIs to reference a survey response.
• Surveys' launch context should now contain a "launch_timezone" in conjunction with the "launch_time" which is the timezone's ID when the survey was launched.
• survey_response/read will now return the UUID value instead of the DB ID when the "return_id" parameter is true.
• survey_response/update now expects the survey response's UUID instead of the DB ID. This can be retrieved from the survey_response/read call as it was done before.
• survey_response/delete now expects the survey response's UUID instead of the DB ID. This can be retrieved from the survey_response/read call as it was done before.