Best Practices for Using the CER Configuration API

Backward Compatibility

Avoid unnecessary dependence on the order of fields within a response object. The order of fields may change in later releases.
Applications should ignore or provide generic treatments (display/log a message, abort senstive operations, etc.) for any unknown response object fields, field values, or HTTP headers/status codes which may appear in later releases.
API elements present in earlier versions will remain, maintaining their previously stated meaning/behavior in every way possible in later versions. They will remain consistent even when defects with them need to be corrected.
Applications should not depend on defective API behavior not consistent with the published API specification. Fixes in later versions could modify such invalid API behaviour.
Developers should be aware that new product features may not always be forward-compatible with applications developed to a previous version's API specification. New features may require application modifications in order to be accessed.

Developers may find the Postman REST API test tool helpful for learning/experimentation.
Always test your application's highest expected API usage rate in a lab setting (while monitoring CER platform performance metrics) before deploying.

Always protect secrets like API user credentials at motion and at rest, for example: store/persist in encrypted format; avoid transmitting or holding secrets in-memory as clear text.