Design Principles | Candid

We strive to keep our API integration experience seamless. When making API design decisions, we do the following:

We aim to use the same APIs internally that you use. This allows us to catch errors early and to make sure that our API is easy to use.
We aim to make our API simple. We want to make sure that you can get up and running quickly. We also want to make sure that you don’t have to write a lot of code to use our API.
We aim to make our API consistent. Whether it is naming conventions, data types, or the way that we pass back errors, we want to make sure that our API works similarly across different services and endpoints.
We aim to make our API reliable. We want to make sure that our API is always available and that it always works as expected.
We bias against breaking changes. We try our best to make sure that you don’t have to make changes to your existing code unless there is a good reason.
We aim to use the same terminology that you use. We want to make sure that our API is easy to understand and that you don’t have to learn a new vocabulary to use it. Sometimes, you may find issues before we do. You may find places where we can do the things above better. If you do, please let us know! We are always looking for ways to improve our API, and you can reach our Support team.

We strive to keep our API integration experience seamless. When making API design decisions, we do the following:

We aim to use the same APIs internally that you use. This allows us to catch errors early and to make sure that our API is easy to use.
We aim to make our API simple. We want to make sure that you can get up and running quickly. We also want to make sure that you don’t have to write a lot of code to use our API.
We aim to make our API consistent. Whether it is naming conventions, data types, or the way that we pass back errors, we want to make sure that our API works similarly across different services and endpoints.
We aim to make our API reliable. We want to make sure that our API is always available and that it always works as expected.
We bias against breaking changes. We try our best to make sure that you don’t have to make changes to your existing code unless there is a good reason.
We aim to use the same terminology that you use. We want to make sure that our API is easy to understand and that you don’t have to learn a new vocabulary to use it. Sometimes, you may find issues before we do. You may find places where we can do the things above better. If you do, please let us know! We are always looking for ways to improve our API, and you can reach our Support team.