Best Practices and Other Basics

• Request limits are dynamic based on CPU load, number of requests being processed and time taken to process the requests. When exceeded we send a 429 retry-after message. This can be picked up in the Header of the message. To solve, please consider adding retry logic in the API calls.

• In order to write an integration correctly, start with the getEntityFields operation to validate the current fields on an entity.

• Use createOrReplace instead of insertEntity when possible so you don't have to execute a query to determine if an entity exists before you update it.

• Retrieve and update the minimal list of fields needed to accomplish the task (use the fieldsRequest parameter). A request that returns a few fields will execute more quickly and transfer less data over the network. If the list of fields to be returned is not specified, PPM Pro will return a default set of fields for the entity. The default list contains most fields, but can change over time. Using the default list is a bad practice because the integration can break if PPM Pro changes the default, and tends to transfer much more data than needed.

• Use selectEntity instead of findEntity if you know the entity ID. It is possible to use findEntity with a searchValuePair based on the entityID, but it is faster to use selectEntity.