REST API References or REST API Models?
Let's demystify the API.
APIs aren't just for programmers anymore. Don't get me wrong: application APIs are still a powerful tool for software engineers and developers who want to CRUD (create, read, update, delete):
- Create: Add a record to Project Insight (e.g. create a project or a task, create an issue or todo, add a file, etc)
- Read: Also known as "get" (As in "get me a list of all the active projects in Project Insight")
- Update: Make a change to a record to Project Insight (e.g. change the state of a project or a task, reassign an issue or todo, replace a file, etc)
- Delete: Boom! It's gone! (Our API lets you do this in certain cases - please use carefully!)
But that's not the the primary use case for APIs any longer. In this post-atomic age of ours, end-users like me are using Project Insight's REST APIs to build reports using Excel and PowerBI and other reporting tools. Once you know how to read our API, decipher our objects and models, and use your preferred tool of choice to dabble in REST object URLs, you'll see how user-friendly these "developer" tools can be.
All you need is:
- A Valid Project Insight workspace*
- System Administration privileges to generate your own API Token OR a token generated by a System Administrator to maintain your permissions
- An API URL from your Project Insight workspace
*TIP: If you are Creating, Updating or Deleting records, you should definitely test your integration on a Sandbox Testing Environment and not your production site.
If you are just reading or getting data, go right on ahead, you won't mess anything up.
Please sign in to leave a comment.