”We need our systems connected” can describe a small API project or an unowned integration programme. For an API integration agency, the better opportunity is not necessarily the biggest technology stack. It is the brief where data flow, access, operational ownership and acceptance tests can be defined. This guide helps integration consultancies qualify new business before committing to a detailed proposal.
Seven signals of a qualified integration brief
- Business event: what decision or workflow must the integration enable?
- Systems: which source and destination platforms, versions and owners are involved?
- Data: which objects, volumes, fields and sync frequencies are in scope?
- API readiness: documentation, sandbox access, limits, webhooks and vendor contracts.
- Security: who approves permissions, personal data handling, logging and retention?
- Operations: who monitors failures, queues, retries and incidents after launch?
- Commercial fit: budget, technical sponsor, buying authority and delivery window.
Know when it is not an API integration project
A transactional connection between an ecommerce platform and an ERP is not the same as building a new analytics platform. A data engineering consultancy may be a better fit for warehousing and transformations. A CRM migration specialist may own data cleansing and cutover. API integration work typically centres on contracts, authentication, events and reliable exchange between existing systems.
Three very different project shapes
- Commerce to ERP: orders, stock, prices and returns need conflict rules and protection against duplicate processing.
- SaaS to customer infrastructure: tenant isolation, versioning, authentication and custom mappings often drive scope.
- Internal workflow automation: approvals, webhooks, retries and audit trails matter even when there is no visible user interface.
Sell discovery before promising a fixed delivery
Do not quote a fixed build until the team has seen the API documentation and access conditions. Offer a bounded discovery: integration map, risks, example payloads and a proof of the highest-risk exchange. Then define acceptance tests for downtime, duplicated events, changed schemas and partial failure. The value of discovery is a credible delivery decision, not a thicker document.
Retries and idempotency matter because replaying a request should not accidentally create duplicate orders or charges. Microsoft documents idempotency patterns for service interactions, while OWASP identifies broken object-level authorisation as an important API security risk. These are useful checks, not claims about any prospect’s systems.
Questions to ask before issuing a proposal
- Does the buyer control access to both systems and a safe test environment?
- Who owns the data contract and decisions when source systems disagree?
- Which errors must trigger alerts and who responds?
- How will credentials, token rotation and per-tenant permissions be handled?
- What happens on timeouts, duplicates and API contract changes?
- Can both sides commit to a realistic test and cutover window?
- Who owns code, runbooks, support and change budgets afterwards?
Position your agency for the right match
State the integration patterns, platforms and business situations you actually support. Be clear whether you deliver discovery, engineering, security review, observability or ongoing maintenance. A de-identified project outline can demonstrate how you work without inventing client results. Avoid claims such as ”every API” or guaranteed launch dates before access and dependencies have been checked.
Mosai helps buyers discover relevant agencies and gives providers a way to be considered for suitable projects. Matching depends on project fit; lead volume is not guaranteed. See For Agencies and pricing options for the current commercial model.
Red flags worth disqualifying
Pause a lead when nobody owns the integration, the customer cannot provide access, or a fixed deadline is demanded without documented API constraints. A well-reasoned no protects delivery capacity. Collect a short brief covering objectives, systems, risk, budget and decision owners before investing in the next sales conversation.
Technical references: Microsoft on idempotent service interactions and OWASP on API authorisation.