Many third-party services and technology can help your team provide IT service. JIRA, Active Directory, and Beyond Trust (formally Bomgar) are a few examples. Using these tools in concert with each other is vital to getting the service data your team needs. So, when considering an ITSM platform, it is critical to understand the availability of integrations.

But what are the differences between the types of integrations out there? Here are the four major types of third-party integration methods available. Let’s also highlight the pros and cons of each for your service team.


1. API

Application Programming Interface (API) is the most common tool for connecting different applications. There are many different types of API that are either public, partner, or private. What they all have in common is how they enable interaction between applications. An API uses a common code language to specify functionality and set protocols. This gives your applications the ability to transfer data.


  • Highly Flexible: Because the integration uses product code, it is flexible when it comes to specific data. The only limitation is that it is dependent on developer resources.
  • App Changes Aren’t Disruptive: APIs are often limited in scope. So, service providers can offer more functionality without affecting other third-party systems.
  • Widely Available: As stated earlier, API is the most common tool for third-party integration. So, it will be unlikely that you run into a service that won’t offer API integration options.


  • Dependent on Vendor: Vendors are responsible for creating APIs. So, you are reliant on the vendor to create APIs for the specific type of information you are trying to pull.
  • Code-Intensive: Because they are code-based, APIs need an understanding of programming languages to install.



Webhooks or HTTP callbacks are an alternative to APIs. They are quite similar in that they are tools that link to a web application. But, they have two key differences. For webhooks, implementation is often not code-based. They often have modules that are programmable within a web application. Instead of being request-based, webhooks are event-based. They only trigger when specific events occur within a third-party service.


  • Real-Time Data: Webhooks don’t use a request-based system. They allow your team to view data on a real-time scale.
  • Supports Automation Efforts: Because data requests are event-based, you don’t have to set up poll timings to your data centre. This can help streamline data flow and automation.


  • Limits Data Manipulation: A webhook requires the service to trigger a data transfer based on an update. In contrast to webhooks, APIs can list, create, edit, or delete an item without triggering a transfer.


3. ISC

Unlike code-based integrations, an Integration Services Component (ISC) lives on a local server. The ISC creates a bridge with on-premise tools such as directories, asset management tools, and BI tools without the need for file imports.


  • (Near) Out-of-the-Box Solution: The ISC immediately offers many data synchronization options you would likely use.
  • Wider Range of Functionality: With an ISC, you can do anything with the data you have access to. Any data that you can access on the backend with your cloud service will be available.


  • Knowledge of Database Architecture Necessary: If you are unfamiliar with how your local database is set up, implementing an ISC will be challenging.
  • Requires Access to the Backend of Your Applications: There will be many cases where backend access isn’t there for your team, so you won’t be able to use an ISC in those situations.



The most automated integration option is orchestrations. If you are not familiar with orchestrations, they refer to the process of automating multiple systems and services together. Teams will often use software configuration management tools such as PowerShell to build orchestrations. Software configuration management tools offer various methods such as snap-ins or hosting APIs to connect with applications to manage the automation workflow.


  • Full Automation: After you build out orchestrations, you can automate across all processes.
  • Manages Multiple Systems: With orchestrations, you can manage the integrations of multiple systems collectively.


  • Code-Intensive: You need to have coding skills to manage your software configuration management tool.
  • Labour-Intensive: Because the workflows are quite complex, the setup can be a drawn-out process. Also, any asset or process changes force you to check how it will affect your orchestrations.

Make sure you check what integration options your ITSM provider offers before you commit. You can learn how Vivantio specifically links up with CRM systems, development tools, and other tools in our recent webinar, “Integration using APIs, webhooks and webmethods.”