How and why I built RESTful Web API for Autotask

Published Jan 22, 2018Last updated Feb 22, 2018
How and why I built RESTful Web API for Autotask

About me

I am a web developer who uses Microsoft stack mainly for server-side constructs.

The problem I wanted to solve

Autotask has a great API, but it is based on SOAP which means if it is to be used by client-side frameworks such as JavaScript/jQuery, there would be a need to wrap the API into something RESTful. One of my customers insisted to work with a custom, commercial HTML5 admin template for his customer portal (meant for his customers). I advised against it for security and ease of development reasons. I am sure you already know that plain HTML5 websites are OK, but not web applications because web apps need security more than plain websites. This is because users tend to interact, create content on the web apps more and authentication scenarios are stricter. This demands for a secure web app template such as that with ASP.NET or ASP.NET MVC. His insistence on using HTML5 propelled me to wrap Autotask SOAP API into ASP.NET Web API which is RESTful and can be invoked from JQuery/JS.

What is RESTful Web API for Autotask?


Tech stack

ASP.NET Web API v2.2

The process of building RESTful Web API for Autotask

Started wrapping calls to SOAP API under the Web API.
One API controller class per Autotask entity
Some extra controllers for joins and stuff
Basic Auth (Autotask supports only Basic Auth (e.g. 'Basic xxxx' in the Auth header at the moment ). You may see it working at this link.

Challenges I faced

Initial challenge was to understand how the authentication works. The Autotask Sample API code used obviously a SOAP proxy in C# and hence the authentication was under wraps. However, I figured out that it is nothing but Basic Auth by using Postman app. After that, it was quite simple.

Key learnings

I love things like making stuff work with each other. Interconnectivity using API, Webhooks, Zaps and mashups. I love web app frontend side (HTML5, JS/jQuery and CSS) as well, but it is highly preferential and subjective. Some people love web pages which look busy with a lot of ads and some people like slick pages (like Zapier,, PayPal and Twitter). That's why I prefer server-side.

Tips and advice

Always target microservices architecture even when you begin.
Always target RESTful services and APIs for easy promotion and collaboration. (see Google APIs, GitHub APIs, Yelp API, PayPal APIs, Authorize.NET APIs, Stripe APIs, and so many more).
Always target for stuff that will still be working for at least next 5 years. No one has seen beyond 5 years in this industry. Hope you all agree with me.

Final thoughts and next steps

I have already started building a Zapier App for Autotask (currently their own Zapier app has only two triggers like New Contact and New account, but no actions and searches). I have added four actions (create Task, Ticket, Account and contact) and two searches (account and contact). I am planning to add more actons, and searches. I am not planning to do anything on triggers though because Autotask's own triggers will suffice when they add more. If you would like to try this Zapier app and see it working, please let me know. This is a real Zapier app (currently private), but I can promote it slowly by sharing the info with community and Autotask dev team as well.

Discover and read more posts from Prasad Narwadkar
get started