How to answer an RFP integration question with unknowns

Response basis

Answer the evaluated integration, not an imagined system estate

Read the integration question with the evaluation method, technical schedules, architecture diagrams, data definitions, security annex, service levels, clarification answers, implementation plan, price model and draft contract. Identify the requested output: an approach, a design, evidence of existing compatibility, a delivery plan or a binding commitment. A technically rich answer can still score poorly if it never addresses the stated outcome or hides the commitment inside a generic architecture narrative.

Create an evidence state for every external-system claim. Confirmed means a current buyer document or authorized observation supports it. Proposed means the bidder is offering a design under its control. Assumed means the response, schedule or price depends on a value that still needs confirmation. Unknown means no defensible value exists. Do not label the bidder’s preferred API pattern as a buyer fact. Do not call an interface supported because the product has connected to a different implementation of the same brand.

The fictional North Coast Works Agency is procuring a field-maintenance coordination service. Its documents name an asset register, a contact-centre platform, a contractor gateway and a finance system. Only the asset register has a draft API description. The answer therefore commits to four governed exchanges and a contract-validation method. It proposes, rather than asserts, how the other three will interact. The fictional case is not evidence about any real authority or system.

Exchange semantics

Define what the exchange means before choosing how it travels

Give each exchange a stable identifier and describe its business contract: trigger, initiating party, source of truth, business object, required fields, identifiers, lifecycle state, expected result and time relevance. “Send a work order” is incomplete. State whether acceptance means syntax accepted, order created, contractor assigned or work scheduled. A 200 response can prove transport success while the business transaction later fails. The response must distinguish acknowledgement from completion.

Next describe the information contract. Define field meaning, units, time zones, code sets, required and optional values, null behavior, identifiers, relationships, examples and schema version. OpenAPI can describe HTTP interfaces, AsyncAPI can describe event-driven interfaces and JSON Schema can express data constraints. None determines the buyer’s business meaning. Cite the exact specification version proposed, explain which parts remain buyer-controlled and avoid claiming that machine-readable syntax alone proves interoperability.

Only then state the transport and identity proposal. Include endpoint ownership, protocol, message or file format, authentication class, authorization scope, encryption boundary, network route and size limits at the level the bid can safely disclose. Route detailed control design to the security answer. The integration section should show how identity and access affect the exchange without publishing credentials, private endpoints or defensive configuration.

• Name the business event and the authoritative owner.
• Separate receipt, validation, acceptance and business completion.
• Define identifiers and correlation across both systems.
• Version schemas, examples, code sets and error definitions together.
• Mark every buyer-controlled field or behavior as a dependency.

Interaction choice

Real time, events and files solve different operational problems

Choose an interaction style from the business deadline, dependency tolerance and recovery need. A synchronous request fits a user action that needs an immediate decision and can tolerate the called service’s availability. A message or event fits work that can complete later and needs buffering or independent scaling. A scheduled file can be appropriate for controlled reconciliation of a large population. These are not maturity levels. A needless real-time dependency can make the service less reliable, while an unexplained batch can make an urgent outcome too late.

State the behavior when the preferred route is unavailable. North Coast can validate an asset reference during work-order entry if the register responds. If the tender permits local reference data, the service may use a dated approved snapshot and visibly mark that validation as deferred. If the business rule requires live authority, the order must pause rather than invent an asset. The response should state which behavior is offered and what buyer decision it depends on.

For contractor updates, an event may carry a change once and allow several consumers to react. CloudEvents can provide a common event envelope, but it does not define the maintenance-status vocabulary or delivery guarantee. The answer still needs event identity, producer, subject, event time, schema, ordering scope, duplicate handling, retention, dead-letter treatment and reconciliation. If the contractor gateway supports only a daily export, the same business states require a different timeliness commitment.

Failure behavior

A credible integration answer explains the second attempt

List expected failure classes: invalid content, unauthorized caller, unavailable dependency, timeout, rate limit, partial processing, duplicate request, out-of-order event, expired file, schema mismatch and unknown business reference. Define the observable response and who can act on it. RFC 9457 provides a machine-readable pattern for HTTP problem details, while RFC 9110 defines HTTP semantics including when methods are idempotent. Those standards help describe behavior; the application must still decide whether repeating a specific business command is safe.

Retries need a budget, delay policy and stopping rule. Retry only failures judged transient, apply backoff, respect server guidance where available and avoid synchronized storms. A retryable transport operation can still duplicate a non-idempotent business action. Use a stable business or idempotency key where the receiver supports it, persist the outcome and return the prior result for a repeated command. If this cannot be guaranteed across the boundary, expose the uncertainty and require reconciliation before reissuing the action.

No integration is complete without reconciliation. Compare sent, received, accepted, rejected and completed records by a shared correlation reference and time window. Preserve enough evidence to explain a difference without exposing sensitive payloads in general logs. For the finance batch, North Coast checks record count, amount totals and an identified rejected-row file before the posting is accepted. One missing record is not hidden by an equal overall value.

Operating ownership

Assign the connection after go-live, not only the build task

For each exchange, allocate specification, endpoint, adapter, transformation, network route, identity configuration, certificates, test data, environment, monitoring, alert triage, incident diagnosis, replay, data correction, support and version change. Name the deliverable and decision authority, not just a RACI letter. A supplier can own an adapter while the buyer owns the endpoint and an incumbent owns the schema. The response must show how those three parties establish one accepted outcome.

Turn external inputs into dated prerequisites. “Buyer to provide access” should state which environment, identity, scope, representative data and connectivity proof are needed by which milestone. State what work can continue if the prerequisite is late, when the critical path changes and how the impact will be decided under the tender and contract. Do not invent a contractual relief mechanism. If the procurement terms place the risk on the bidder, reflect that in the design, schedule and commercial approval.

Define operational visibility on both sides. A shared correlation identifier and W3C Trace Context can help connect technical traces where the parties support them, but trace propagation does not replace business audit or incident ownership. State which health, latency, backlog, rejection and reconciliation measures each party can observe, how alerts cross organizational boundaries and which evidence is retained for support. Avoid promising access to logs controlled by another party.

• Attach every prerequisite to a milestone and acceptance check.
• Separate technical alert ownership from business-correction authority.
• Name the party that can authorize replay or reject a corrupted exchange.
• Define support handoffs using evidence both parties can obtain.
• Carry third-party lead times into the committed schedule.

Verification

Test the contract, the failure and the business outcome separately

Build a verification chain from each requirement. Static specification review checks that operations, messages, required fields and errors are defined. Schema and contract tests exercise examples and compatibility at the boundary. Component tests prove the bidder-controlled implementation. End-to-end tests prove identity, network, both endpoints and the resulting business state. Negative and degraded tests show rejection, retry, queue, recovery and reconciliation. Volume tests use stated load shapes rather than a convenient row count.

For every test, state the environment, specification version, controlled inputs, expected observable result, evidence, defect treatment and acceptance owner. A sandbox success may not prove production routing, limits, certificates or third-party behavior. Say what conclusion each environment supports. If representative data cannot be supplied before award, commit to a test-data design and validation gate, not to results that do not yet exist.

North Coast’s contact-centre scenario sends the same work-order command twice after a simulated timeout. The expected result is one work order, one stable identifier and a retrievable prior outcome. Its contractor scenario holds the consumer offline, restarts it and proves that retained updates are processed once or identified as duplicates before reconciliation. The finance test introduces one invalid account code and expects a visible rejection without silently dropping the other control totals.

Change control

Compatibility is a claim about an existing consumer

Baseline the interface description, schemas, examples, code sets, security profile, limits and runbook used for acceptance. A change that is syntactically additive can still alter behavior. A new required workflow state, different default, narrower authorization or lower rate limit may break an existing consumer without deleting a field. Google AIP-180 distinguishes source, wire and semantic compatibility in its own API guidance. Use the same discipline to ask whether existing participants continue to behave correctly, not merely whether a parser still accepts the payload.

Define who may propose and approve a change, the notice and assessment path, compatibility evidence, parallel-run or deprecation window, rollback plan and documentation update. Do not promise a universal notice period unless the tender or an owned service supports it. For buyer or third-party interfaces, state the assumed change conditions and the contractual or governance route for effects on scope, price or schedule. Keep that route consistent with the draft contract.

The final response should be concise because its supporting contract is structured. For each exchange, give the outcome, evidence state, proposed behavior, responsibilities, failure treatment, verification and open confirmation. Then summarize common governance once. Cross-reference security, migration and service answers rather than restating them inconsistently. The approver should be able to trace every commitment to evidence, an owner and an acceptance condition.

Unknowns

Use a validation path where a final interface fact does not exist

Ask a clarification before the deadline when an unknown changes compliance, a mandatory architecture constraint, material price, deliverability or comparison between bids. Cite the conflicting or missing tender source and request the smallest answer that changes the bid. The separate interface-clarification discipline owns that question process. This response owns the result: it must incorporate the buyer’s answer or show the remaining bounded assumption, not leave a vague promise to agree details later.

When post-award validation is unavoidable, state the decision to be made, inputs required, responsible parties, milestone, offered default or options, success condition and consequence if the assumption fails. For example: “The proposed event exchange assumes the gateway can retain status events for at least the agreed recovery window. Within ten working days of authorized sandbox access, the parties will test retention and replay against the versioned contract. If unsupported, the scheduled export option will be assessed through the agreed change route.” The actual period and route must come from the bid and contract, not this example.

Stop the answer from crossing authority boundaries. Do not publish secrets, assert access never granted, approve buyer data meaning, accept security risk, bind an incumbent or promise legal compliance by architecture alone. An integration lead can define observable behavior and evidence. Authorized business, security, privacy, commercial and contractual owners decide the obligations in their domains.