API proof criteria should be observable at both systems

Use given, when, then, and evidence

Write each criterion with a starting state, action, expected result, and evidence location. Given a sanitized approved customer record and an authorized proof identity, when the connector submits the mapped request, then the target sandbox contains one case with specified fields, and the evidence includes joined source, request, response, and target identifiers. This is more reviewable than works with the target system.

Add the permitted input range and environment. State which optional fields are included, which enumerations are mapped, which timezone or currency rules apply, and which target side effects are allowed. The OpenAPI Specification provides a language-agnostic description for HTTP API operations and schemas, but an interface description does not supply the workflow semantics or acceptance decision. Those still require buyer and prospect agreement.

Include one rejected case and one retry

A working happy path leaves major implementation questions unanswered. Include a representative invalid input and specify the expected validation response, target-system non-action, error record, and visible explanation. Include a safe transient failure or recorded fallback and specify what can be retried, whether the operation is idempotent, how duplicates are detected, and which identifier lets an operator trace the attempt.

Timing should be measured as an observation under the proof conditions, not a service-level promise. Record the environment, payload size, start and end points, and several runs when useful. If the prospect has a required threshold, label it as a buyer-approved criterion and record pass or fail. Do not generalize a small proof run into a scalability, availability, or production-performance claim.

Separate pass from acceptance authority

The automated suite can mark whether observed results match the written criteria. It cannot decide whether the criteria are sufficient for procurement, security, compliance, architecture, or production use. The evidence book should name who approved the criteria, who witnessed the run, each exception, and the person authorized to accept or reject the proof for the next commercial conversation.

Reality Contact, LLC implements these checks through Integration Proof Record. The buyer controls API and target access, and the buyer and prospect approve every criterion and claim. A passing criterion establishes only the named behavior with the named sanitized input and environments. It is not a security review, compliance assessment, architecture approval, production signoff, or outcome assurance.

Where the service stops

Reality Contact, LLC builds a one-workflow evaluation artifact but does not certify security, privacy, compliance, reliability, scalability, production readiness, procurement fit, or business outcomes; approve enterprise architecture; operate production; or represent the prospect's acceptance decision. The buyer and prospect approve the workflow, claims, sanitized data, constraints, target-system actions, and acceptance criteria; control credentials and access; attend the evidence review; and decide whether to commission a separately scoped production implementation. The service is software implementation and document preparation for one evaluation workflow, and it does not replace security, privacy, compliance, architecture, procurement, reliability, or production review. The buyer and prospect approve the workflow, data, claims, access, and acceptance criteria and retain every production, procurement, architecture, and commissioning decision.