D. General Notes
Client IDs
When creating objects you may provide a client_id. This is a value, only applicable to your integration with our API, that will allow you to identify your objects for update requests. Each client_id must be unique for each object type (e.g. you cannot have the client_id “abcdefg” for more than one user, but you may have it for a user and an exhibitor). We provide this capability so that you do not have to save and recall the Zerista IDs for each request. The format of the client_ids is unrestricted except that it cannot exceed 64 characters.
Users and Exhibitors may have more than one client_id. This is useful if your event has multiple organizations implementing integrations. To add a client_id to a user, simply pass an update request with the new client_id, and the system will automatically match based on the user’s email address and add the new client_id. For Exhibitors, this works the same way except the match is based on the company name. Multiple client_ids is not yet supported for Events.
Encodings
Zerista requires that all character data is encoded in UTF-8. Likewise, all response data will have a charset of UTF-8, unless the Content-Type header specifically states otherwise.
422 Errors
Zerista uses the 422 response code to indicate that the request was rejected because of invalid data (e.g. an invalid email address or attempting to create a user that already exists). The response will include information as to the exact cause of the rejection.
Password resets on API keys
Every API key is directly associated with a user account. This is so that we have an accountable individual for each key we generate. If the user that is associated with the API key resets their password, the API key will immediately loose it’s permissions. Please contact Zerista if you require a password reset on the user account that is associated with your key. Note: this section is not applicable with User-Mimicking via Token Authentication.
HTML Requirements
If a field accepts HTML, it must be “strictly valid” HTML 4.01 (see http://www.w3.org/TR/html401/). We also highly recommend that your HTML passes XML validation since we validate all HTML input via an XML parser. For example, our validator will consider unclosed elements like <br> as invalid, and the request will be rejected.
