Questions to ask an API development services vendor before you sign

Ask five things: whether you will sign the API contract before code starts, how a breaking change reaches live consumers, who owns the code and the cloud account, what the system will cost to run each month at your volume, and what handover looks like on the day you leave. A vendor who has shipped answers all five without hedging.

This article is the question bank we would use if we were buying API work rather than selling it. Each question is grouped by what it actually tests, with the answer that should reassure you and the answer that should not. It is written for the person who has to sign the statement of work, not for the engineer who will read the pull requests.

Why the questions that separate vendors are not the technical ones

Almost every firm can describe REST, OAuth 2.0 and JSON fluently. Technical vocabulary is table stakes and tells you nothing about delivery risk. What separates a team that has run APIs in production from one that has only built them is the unglamorous operational detail: what happens when a partner sends the same request twice, what happens when a field has to change shape, what happens when the payment gateway you depend on starts timing out on a Friday evening.

The questions below are uncomfortable for a vendor whose portfolio is greenfield demos. None of them require you to be an engineer. Each has an answer that a team who has carried a pager can give in one sentence, and a hedge that a team who has not will reach for immediately.

One framing helps throughout. You are not buying endpoints. You are buying a contract that other people, some of whom you will never meet, will write code against and then hold you to for years. Almost everything expensive about API work comes from that contract being wrong at the start or changing badly later. Eazyware's API development and integrations engagements begin with the contract for exactly that reason.

Six questions that do most of the work

Most due diligence lists run to forty questions and collect forty paragraphs of marketing. Six areas carry nearly all the risk, and each has a question that is hard to fake.

Five of those map to the areas in the opening paragraph. The sixth, reliability, is the one buyers forget and the one a team who has been on call raises unprompted.

Questions about design

Will we sign the contract before you write the code?

The answer should be yes, and you should be reading an OpenAPI document before anyone opens an editor. A specification agreed up front lets your team, your partners and your test harness work in parallel, and it makes scope disagreements cheap because they happen in a document rather than in a sprint review. Ask to see a specification from a previous project with the client details removed. If none exists, documentation is being written after the fact, which means it will drift from behaviour within a month. API-first SaaS: designing the public API before the UI sets out why the order of work matters more than the tooling.

How will you version, and how long do old versions live?

You want a named policy, not a principle. A good answer sounds like: additive changes ship without a version bump, removals and type changes require a new major version, old versions are supported for a stated number of months, and consumers get deprecation headers plus a migration guide. A vague answer means the first breaking change will be an incident. If the API sits over an existing system, ask how they will stop internal schema changes leaking straight through to consumers.

What happens when the same request arrives twice?

Networks retry. Mobile clients retry. Queue consumers retry. Any write endpoint that can charge money, create an order or send a message needs an idempotency key and a record of which keys have been seen, so that a duplicate returns the original result instead of doing the work twice. The same discipline applies outbound: your webhooks will be redelivered, and consumers need signatures and replay windows to trust them. Stripe's webhook documentation describes the signature verification and retry behaviour that a competent integration has to handle, and it is a fair benchmark to hold a vendor to.

Questions about ownership, exit and the monthly bill

Ask who owns the repository, the specification, the infrastructure-as-code and the cloud account, and ask when. The honest answer is that you own all of it from the first commit and the work happens in your accounts. Anything else creates leverage you did not agree to buy. Code and IP ownership is a contract term, not a goodwill gesture, and the contract terms that matter are worth reading before the negotiation rather than during it.

Exit is the question nobody asks in a first meeting and everybody regrets skipping. A vendor who expects to be replaced eventually builds for it: runnable local environments, a README that a new engineer can follow, architecture decision records, and credentials held by you. Ask what their last handover involved and how long it took. If the answer is that no client has ever left, either the firm is very young or the question is being dodged.

The monthly bill deserves its own conversation. Build price is the smaller number over three years. Gateway charges, egress, logging and trace retention, secrets management, a staging environment that nobody remembered to size down, and the engineering hours to keep third-party integrations working all land after go-live. Ask for a written estimate of monthly running cost at your expected request volume. Total cost of ownership is the honest frame, and the hidden costs that quotes leave out lists the ones we see missed most often.

What should an API development engagement cost?

Eazyware's API development and integrations work starts at $7,000 or ₹4,40,000 and runs to $35,000 or ₹23,20,000 depending on how many systems are in scope and how much of the data model already exists. A single well-understood integration sits near the bottom of that band; a partner-facing public API with authentication, rate limiting, sandbox keys and documentation sits near the top. Post-launch cover is a separate line: Care Plans run from $1,000 or ₹68,000 a month for Essential through $2,500 or ₹1,60,000 for Standard to $5,250 or ₹3,40,000 for Enterprise with a named engineer. All of it is published on the pricing page, and a vendor who will not publish comparable ranges should be asked why.

If the scope is still moving, a ten-day Sprint Zero produces the specification, the integration inventory and a fixed price before anyone commits to a build. That is cheaper than discovering scope in month two of a time-and-materials arrangement.

Eight questions to ask on the reference call

Ask for a reference whose project shipped more than a year ago, because the interesting failures show up after the first few releases.

• Did the API you signed off match the API you got? Drift between specification and behaviour is the most common quiet failure.
• How did the first breaking change go? The answer tells you whether the versioning policy was real.
• What did the first month after launch cost to run, and was it what you were told?
• Who was on the call during your first production incident, and how long did it take?
• How long did it take a new engineer on your side to make a change unaided?
• What did they say no to? A partner who never pushed back was selling hours, not judgement.
• Were the tests handed over runnable on your machines on day one?
• Would you give them the next integration without going back to market?

When this list is the wrong list

If the job is genuinely small, for example one internal endpoint that a single team will call, running full due diligence costs more than the work. Ask three questions instead: who owns the code, what it costs to run, and who answers the phone when it breaks. Over-specifying a two-week job is a real way to waste a month.

This list is also wrong when the actual problem is not API delivery at all. If nobody can say which system is the source of truth for a customer record, no API vendor can rescue that. Fix the ownership question first. The same applies when the integration target is a platform whose own API is the constraint: that question belongs to its vendor, not yours.

What good looks like once the answers check out

On a last-mile logistics programme, the API work was not a standalone project but the layer that let a dispatch platform speak to an existing transport management system, telematics feeds and a driver application that spent much of its day offline. The design questions above decided the shape of it: signed contracts first, idempotent writes so a driver device could retry safely, and versioning that let the older system stay still while the new one moved. The dispatch platform and driver app case study describes the result.

Related reading

What to put in an API development services RFP turns these questions into a document you can send to three firms, and five ways API development projects fail covers what happens when they go unasked.

The vendor worth signing is the one whose answers get more specific as your questions get harder.