Is It Out of Scope? — Web development
Is integrating a new third-party API out of scope for a web development project?
Usually yes, unless it was named in the original feature list — a new integration brings its own auth, error-handling, and ongoing-maintenance surface the SOW didn't budget for.
The build was scoped around a specific set of integrations (or none). A request to add a new one — a CRM sync, an analytics platform, a payment or shipping provider not in the original spec — comes in mid-build or post-launch. Even a well-documented API involves real work: auth setup, error handling for the integration's failure modes, data mapping, and often ongoing maintenance as the third party's API changes over time.
Is it out of scope?
Yes, unless that specific integration was named in the original SOW. "It's just an API" undersells the work — every integration is its own auth, error-handling, and long-term maintenance surface, and none of that was budgeted for an integration that wasn't originally in scope.
Clause typically implicated
Clause typically implicated
Deliverables clause→ — Named integrations are typically listed explicitly in the SOW given their scope impact — an unlisted integration is new work by definition.
Example contract wording
Example contract wording (illustrative, not legal advice)
The [new service] integration wasn't part of the original scope, which covered [list]. Every integration brings its own setup and ongoing maintenance surface, so I'd like to scope this properly — can you share the API docs and what data needs to flow where? I'll put together an estimate from there.
How MarginFlow flags it
MarginFlow checks the requested integration against the contract's extracted, named integration list — a request for an integration not on that list is flagged outside_scope regardless of how simple the client believes the API to be, with the explanation noting the ongoing-maintenance dimension so the account manager can price it as an ongoing commitment, not just a one-time setup fee.