I'm part of a small IT department at a university, and we've been transitioning to more SAAS solutions. We're currently dealing with two vendors: EDUCATE, who manages our ERP SAAS, and PITA, which oversees specific elements of a student major. PITA requires an API endpoint on EDUCATE to keep their student data updated, but they didn't consult us before signing their contract.
EDUCATE supports setting up API endpoints, which we've done for PITA, but now they want those responses to be 'directly consumable' by their application. I want to clarify my understanding of API functionality: typically, an enterprise develops API endpoints and details the format of the requests and responses. The user is then responsible for writing the program that makes these API calls and handles the responses in whatever format is given.
Given that PITA is already aware of how EDUCATE structures its API responses, is it unreasonable for them to ask us to create a response that fits directly into their application? My gut feeling is that they might not be equipped to write the necessary code to interact with our APIs, which raises concerns about who is really responsible for these integrations.
5 Answers
SaaS vendors generally won’t write custom code for individual clients; that’s not their model. As long as you're important enough or have a big enough contract, they might consider it, but for the average case, you’ll likely need to handle the integration as per your provided API structure.
Custom APIs should definitely be discussed during contract negotiations. If PITA can’t adapt to standard APIs, that’s on them to adjust, not you. It's a typical expectation to accommodate clients, but always within reason. If they want a specific setup that requires a lot of work from your side, push back and ask for clearer terms.
They probably can't adapt to your API or want to avoid building their own integration layer. I suggest you push back and ask them for a clear API contract—that way, you won't end up customizing just for them and risking ongoing maintenance issues.
It's pretty common for vendors to ask for APIs that are easy for them to consume. They usually want to avoid maintaining custom code just for one client, so they push that responsibility to you. There are solutions, like Azure API Management, that can help manage these integrations, but it's not unheard of to expect you to provide something they can use without much tweaking.
What they're looking for when they say 'directly consumable' is basically that they don't want to do any extra work on their side to adapt to your API. APIs are supposed to provide a stable contract, and it's up to the client to handle the responses. So, if you’ve given them well-documented endpoints, you're fulfilling your part. Just don't take on the burden of tweaking everything to fit their app unless that's what was agreed upon in your contract.
That makes sense! I just want to ensure we don’t end up doing extra work that's outside of our original agreement.