Plan requirement
| Subscription | Any plan |
| Access | Admin |
The API when configuration is not enough. Where to begin, and the four things to get right first.
What it lets you do
Read and write almost everything: tickets, users, organisations, fields, configuration. Anything the interface does, and some things it does not.
One: use a service account
Not somebody's personal credentials. When that person leaves and their account is deactivated, every integration using it stops, usually on the day they leave.
This is the most common cause of an integration breaking, and it is entirely avoidable.
Two: give it the narrowest role that works
An integration reading tickets does not need admin. Scope it, so a mistake or a leaked token cannot reach further than the job requires.
Three: handle the rate limits
There are limits on how many requests you can make. An integration that ignores them works in testing and fails under real volume, which is the worst time to find out.
Four: log what it does
When something changes tickets unexpectedly, the audit trail is how you find out whether it was a person or an integration. Without logging on your side, that investigation is guesswork.
Try configuration first, genuinely
Triggers, webhooks and fields cover a great deal. Code has to be maintained by somebody who understands it, and that person will eventually change jobs.
Test somewhere safe
A sandbox where your plan includes one. An integration under development writing to live tickets is a category of mistake worth designing out.
Write down what it does
What it touches, why it exists, who owns it, which account it uses. That note is what makes it maintainable, and it is what nobody writes.
Comments
0 comments
Article is closed for comments.