Best Practices

Here are some best practices and tips you can use when developing against the API:

• Avoid making API calls against the default view. These views often take the longest amount of time to load, and therefore will have longer response times.

• Build a custom view to make API calls against. The view should contain the minimum number of fields necessary for your API requests. Avoid field sorting, including complex or large number of calculated fields, and complex view filters where possible. All these will slow down the response times of the view. Learn more about building views here. (opens in a new tab)

• Use indexing to improve response times. If you have an API call that will be searching a table regularly for the same field, you can reduce the load on the search and make it easier to find the item with table indexing. Indexing a field, especially with the “Identical to” search type, helps the find function locate the right record faster. Only put one indexed field on a view to optimize call performance. Learn more here. (opens in a new tab)

• Follow the principle of least privilege. When setting up the permissions for the API User, only give the role access to the views and permissions needed to run the integration actions. This will ensure better data security and integrity. Learn more about roles and permissions here. (opens in a new tab)

• Test in a sandbox environment before releasing to production. Build your API connections with your sandbox ID, production API Key and auth token, and you can utilize your sandbox to test your API calls to check performance and test delete or post actions. This ensures that your data will remain safe while you test your processes and ensure they are working seamlessly before implementing a new process that could alter or delete important data. Learn more about sandboxes here. (opens in a new tab)

• Make the fewest number of API calls possible. If you think that you'll need to make the same API call more than one time, consider storing the response in memory after the first request. This way you can reference the response in memory rather than making the call again. Referencing the data in memory is faster and it will reduce the number of API calls that you need to make (keep you below the rate limits).

Building Views for API use

When building a view for your API, a best practice is to follow the principle of the least privilege and only include the minimum number of fields and records necessary for your Integration. You'll be ensuring better data security and integrity and keeping your API call returns quick. Four key reminders, make sure to avoid default views, column sorting, filters, and unnecessary calculated fields in these views they can each be resource intensive and slow down your return. A default view will contain all the records and fields, and calculated fields must run every time the view is accessed, making both items less performant for API calls. To ensure your API has access, ensure you've shared the appropriate views with your API user specific to your integration.

You can use our API to GET a list of views, a list of records, or a list of filtered records from a view. You can also use our API to POST, DELETE, or GET a record from a view. Make a note of your view IDs in the request URL (i.e. go.trackvia.com/apps/#/tables/#/views/ID #), and you can use Swagger or Postman to test, learn more about different IDs and options with our API, and plan out the build for your API actions.

Indexing Fields for API Calls

If you have an API call that will be searching a table regularly for the same field, you can reduce the load on the search and make it easier to find the item with table indexing. Indexing a field, especially with the “Identical to” search type, helps the find function locate the right record faster. Only put one indexed field on a view to optimize call performance. To learn more about applying table-level indexing, check out our how-to article (opens in a new tab) for more details and best practices.

Sandboxes & Your API

Utilizing sandboxes to test your API connection and results is a great way to check your system and setup before impacting your current data. Build your API connections with your sandbox ID, production API Key and auth token, and you can utilize your sandbox to test your API calls to check performance and test delete or post actions. This ensures that your data will remain safe while you test your processes and ensure they are working seamlessly before implementing a new process that could alter or delete important data.