Best practices
This is some advice on best practices for using the API, regardless of your particular use case. Follow this advice for less errors and better performance.
- 4xx HTTP status codes Follow our recommendations on handling each 4xx response code. If you receive a 400 response with an 'Invalid {Parameter}' message, one possible explanation is that the resource you are referencing doesn't exist - check with the enterprise for confirmation.
- Webhooks instead of polling Instead of periodically polling for updates using a 'get' operation, use Webhooks instead and subscribe to updates. If a Webhook for an event is not supported, reach out to us at [email protected]. For more information, see Ways to communicate.
- Limit use of extents Limit the amount of extents you use as much as possible. You can see an example of extents in Get all resources. An extent represents a related entity that requires lookup into another database table, thus significantly hindering performance. If you need to use multiple extents, instead create a separate call for each individual extent.
- Use pagination Use pagination for 'get' operations wherever possible. Responses will be smaller and easier to manage, and you won't hit those request timeouts!
- Use filtering Avoid retrieving the same data repetitively. Leverage filtering to retrieve just the subset of data that's relevant to you. Data past the Editable History Window can't be changed so it doesn't make sense to pull it repeatedly. If there is no support for a filter you'd benefit from, reach out to us at [email protected] with a request to add it.
- Don't query for unchanging data Querying for relatively static resources adds unnecessary traffic to the API and slows down the user experience. Instead, cache data that doesn't change very often, such as:
- resource categories
- services
- products
- accounting categories
- business segments
- configuration
- taxes
Last modified 2mo ago