Third Party Integrations

How accessible and usable are their docs?

If you google the answer for a question whose answer isn’t immediately obvious, can you find the answer? While their documentation may or may not be complete, most developers will rely on search engines in order to find results. This means that if their documentation is perfect, but is not adequately indexed by google, then it isn’t suitable.

One thing you learn in software development over time is that the idea of RTFM doesn’t work at scale. Most developers (including yourself, under stress) will not read the manual, but will instead look for an indexed, easy solution to a problem. If the provider can’t provide one, then they aren’t suitable.

Some companies will also hide their documentation and require a login to view it. In general, if the problem that you are trying to solve is fairly straightforward, you want to avoid these, as this is an additional barrier to entry for working with their software. You should also check to make sure that documentation is current. Many integrators have been burned by documentation that is a version or two out of date. If you can’t find documentation on the version that you are expected to use, that is the same as a complete lack of documentation.

What is their support like?

While documentation helps a lot, you shouldn’t count on it exclusively. Not every problem with any software package is easily known or quickly resolved. You may have to get in touch with a human being who can dig into problems for you (and/or point you to documentation that you HAVEN’T found yet). You should evaluate whether or not you can quickly get ahold of a human being at the expected level of expenditure for your application. While it isn’t reasonable to expect to get support from a real, live human being for $5 a month, it is reasonable to expect to do so when you are paying hundreds or thousands of dollars a month.

You should also look into their support guarantees. How long is the typical turnaround for getting a response from support. While support can’t usually guarantee a solution to a problem in a certain amount of time, they can and should guarantee a response. This response will let you determine what to do if a problem occurs. Don’t rely on development’s ability to “figure stuff out” when a problem occurs. While you might be able to do so, your response may not be optimal.

How good are their development processes?

Once you’ve evaluated their support processes, you need to get an overall feel for how well their organization can respond to issues, feature requests, and questions by evaluating their support process. Bear in mind that if your users have a problem with their integration, the expected response time of a fix is whichever is worse between organizations. Figure out if that will be acceptable by figuring out how quickly they solve issues.

While this is something that can only be really learned through experience, you can often look at user forums (if any are available) to determine how quickly the company can solve simple issues. You should also look at how frequently they release software updates, as well as their ability to release quick patches for rising issues, when determining the quality of their organization. NOTHING ELSE matters – you are outsourcing because you are more worried about results than implementation. Act like it.

Is their programming model familiar?

When integrating with a third party service, it can be tempting to choose an implementation that has the best features or the lowest price. While that is often a consideration, it isn’t the only one. In particular, if your development team can’t reason about the software, those issues are fairly minor. You need to look at how to integrate with their system and see whether it matches the way you currently do things.

You should also look for things like adherence to web standards. You don’t want to integrate with a software package whose REST implementation uses POSTS where GETs are more appropriate. If it doesn’t confuse you, it’ll confuse the next developer. Similarly, you may find that their API will be difficult to hammer into the way that you work with data. For instance, if they have an old-school SOAP interface when you have already moved on to GraphQL, you’re going to have a bad time.

How do they account for stability issues?

No software is perfect. Whether it is hosted on the cloud or on-premise, something will eventually go wrong, causing the software to stop working for a while. While downtime may be acceptable, lost functionality (or worse, data) is unacceptable these days. If you plan to integrate with other software and they use a webhook to send data back to you, how often do they retry (and over what time period)? If a webhook fails, do you have a means of getting the data some other way?

Basically, when you integrate with a third party, you are introducing another source of truth to your app. Because of this, you need to have a way to keep your data updated so that your primary system can be trusted. If an integration partner makes it impossible or difficult to recover from an outage, they are best avoided.

While you can mitigate many of these issues with infrastructure on your side, if a vendor doesn’t also take these issues into account, then your implementation will have to be considerably more robust in order to achieve a baseline of stability.

What is the testing landscape?

In addition to regular development use, your QA team will likely also be required to do at least some testing with the platform. So you need to consider how well it works for them. In particular, you need things like segregated QA environments, the ability to trigger error codes with certain requests, and the ability to look things up in a dashboard (without API calls) to determine what happened.

The “perfect” integration partner for a development team can be quite abysmal for the QA team. You might be tempted to let this slide, but if you do so, over time this integration point will become a headache. Remember that a big part of QA’s job is testing for regressions. When you have two disparate pieces of software changing separately, the opportunity for regressions is enormous and you need to make it as easy as possible for your QA team to do regression testing in an automated fashion.

What are the restrictions on usage?

You should also carefully consider what kind of limits are placed on your integration with another software package. This can vary a lot depending on why you need the integration, but a great example of this is the case of an email service provider. Email providers will want to limit the volume of email you send, as well as the CONTENT of the emails.

There may also be other legal restrictions regarding how you use data that you get from an external service. This is especially true of financial and personally identifiable data. You should ALWAYS get legal involved in these discussions.

Rate limiting is another issue here. You should determine whether the integration point can deal with the volume of data you are sending. Many integration partners will rate limit to make sure that one client doesn’t disrupt things for everyone else. This is actually a good practice, but is not any fun to be on the wrong side of.

Monitoring considerations

You should also determine what level of monitoring, logging, etc. is available from integration partner, without the requirement of writing code. While it’s great if they have an API for this stuff, you won’t be using the API initially.

This means that you should start out with a dashboard (you’ll likely need this for showcasing things to management as well as QA/Debugging tasks anyway). It should be as simple as possible to determine whether your requests are going through their system or not, without writing code.

You should also pay attention to how quickly the dashboard updates. While a dashboard that updates daily might work in some circumstances, it can be pretty annoying for debugging a problem that just occurred in dev, and can be absolutely awful if a problem occurred in production. You should also pay attention to dashboards that show application stability and availability, as you WILL be wanting those to be of quality when the inevitable outage happens.