Guest Blogs

The API Mirage

Jesse Nobbe & MikeGeller from Tegrita talks about the integration of the martech stack and how API can be more than just an integrating interface
marketing technology

A well-connected MarTech Stack is the difference between a Stack that drives revenue growth and a Stack that stifles it! This means that when you’re reviewing your existing marketing technology or considering new technology to add to your portfolio, assessing how well that technology plugs into your other technologies is a critical consideration.

A standard way of allowing two different technologies from two different (or even the same) vendors to connect to each other is through the use of APIs (Application Programming Interfaces). Not all APIs are created equal. Some are extremely powerful, flexible, and open. Others are limited, brittle, and closed. Many fall somewhere in between.

APIs are a big step forward for interoperability, but they didn’t always exist In times past, integrations between systems were one-offs. Over the years, different methodologies were pioneered to make communicating between different systems easier. SOAP (Simple Object Access Protocol as some refer to it) and later REST (Representational State Transfer) were created to expose a shared vocabulary or interface between different parties. The allure is that integrations are easier to build, QA, maintain, and extend. APIs enable platforms to grow considerably using non-native functionality.

An API call is a request. These requests are written in programming languages such as Python or PHP. Each request is a call, and a specific integration action (like export a list) is typically made up of multiple calls.

Just because an API exists, doesn’t mean it provides all the necessary functionality. In some cases, a feature is only available to the API provider, or to the consumer for an extra fee. Some APIs are poorly documented and may have endpoints that are simply not recorded anywhere except within the code itself. This is an important area of research and consideration when thinking about the total cost of ownership when assessing technology; the vendor may not be the most helpful in supporting this research. If the vendor is able to share robust documentation, it’s usually a good sign that the API is stable and well-developed.

APIs don’t always operate in the way we would like or expect. API consumers are bound to the vendor that provides the API. There may be limits on the number of calls that can be made within a certain time period. There may be a specific set of steps that need to happen before an action can be completed. The API may not provide detailed (or any) responses for successful or failed calls, in which case the development and testing of an API integration become exponentially more difficult.

When doing API research, you’ll want to check for the following things:

  1. Documentation
    1. Do they have any?
    2. Is it robust, with sample code and examples of expected return data?
    3. Is there a live testing environment available to test your code?
    4. Does it support the language you’re planning to use?
  2. Cost
    1. Does the API have an added cost to the technology, if so, what is it? Typically, when API access is an extra fee, it’s also a tiered service with call limits per 24-hour period.
    2. Do you have development resources to make use of the API, or will you have to hire outside consultants?
    3. Where will the API code live and who will maintain it?
  3. Vendor Support
    1. Does the vendor have SLAs in place to resolve issues/errors?
    2. Does the vendor have a history of providing sufficient notice to API changes/deprecation?

Another consideration is whether you even need to use API to achieve your integration objectives! Due to the attractiveness of APIs, other simpler alternatives can be overlooked. Many times, a flat-file-based integration or simple webhook-based integration is enough to get started. From there, an API-based integration can be properly considered and built out. It’s important to note what the objective of the integration is before development and design take place. Many integrations do not require real-time data to be effective; a nightly flat-file import would suffice. Having clearly defined goals and objectives for the integration can save months of development time and can enable the technology to meet its objectives sooner.

APIs make the task of integrating more clear, repeatable, and sustainable. However, along with that comes the need for talented developers and budgets to match. Making sure the job is done right can take a great deal of time. Building an API integration also requires a commitment to maintain the integration, make revisions and troubleshoot issues due to external factors. These factors include: changes to the API itself (perhaps a feature deprecation), a change to standards (a security protocol is being replaced), a better provider has been found (switching the underlying API for another), business needs, and so on.

APIs can be extremely powerful due to their flexible and extensible nature; at the same time, they can be overly complicated, under-supported, and very expensive to operate.

This requires a good amount of planning and consideration on whether the MarTech tools can actually support your business needs.

When thinking about your MarTech stack and how the data needs to flow between the different tech that makes up your stack, you’ll want to make sure you’re looking at your objectives and how they align with supporting revenue growth, along with the integration options – including but not limited to API. Once you’ve made your assessment, you’d have clarity to proceed to the next step of building out the integration and making sure your MarTech stack does what it needs to do: support your revenue growth and improve the customer experience.

Check Out The New Martech Cube Podcast. For more such updates follow us on Google News Martech News


ABOUT THE AUTHOR

Jesse Nobbe, Sr. Technology Lead at Tegrita
Jesse Nobbe is a Sr. Technology Lead at Tegrita. He helps in designing, building, and maintaining robust Rev Tech solutions.

 


Mike Geller, Chief Technology Officer & President at Tegrita
Mike Geller has been working in the marketing technology industry for over 15 years, with the last 10 as a consultant and a technology strategist. As Tegrita’s CTO, Mike’s focus and area of expertise is vetting new technologies and techniques that further the strategic goals of Tegrita’s clients. He also spends time discovering new marketing technology and looks at systems integration to support data transparency. As the CTO, his primary objective is to ensure that our technical solutions are capable, scalable, and maintainable.

Previous ArticleNext Article