Ask what the provider’s reference actually identifies

An integration demonstration may return an identifier immediately after a request. Before showing that value to a customer as their case number, establish whether it identifies the business record, a transport request or a processing operation. Those references can have different meanings and lifetimes.

This fictional procurement decision concerns a provider with an asynchronous creation process. The team is evaluating whether that process can support the organisation’s enquiry journey. It does not submit a real enquiry or assume that every provider follows the same contract.

Inspect the immediate response

The organisation wants customers to receive a reference for a created service case. The provider’s documented create operation returns HTTP 202 with operation ID OP-17. Its contract states that processing has been accepted for later work; the response does not yet contain a business-case ID.

The initial prototype displays OP-17 as “Your case number”. A later status read shows that the operation is still pending and no case exists. The interface has converted a processing acknowledgement into a claim of completed creation.

The distinction is consistent with HTTP’s meaning of an accepted asynchronous request: acceptance for processing is not the completed result. The provider’s own status and business-record contract must still establish what happened in this workflow.

Inspect the supported read-back

The selected provider offers an authorised operation-status read. In the controlled fixture, OP-17 first reports pending with no business-case reference. A later read reports completion and identifies case C-91. An authorised read of C-91 confirms the expected source enquiry reference and fields.

The provider also documents a failed terminal state that may occur without creating a case. The team tests that state separately. It does not assume that every accepted operation eventually succeeds or that a missing case ID means the create request should be sent again.

The account under review has the required permission for the status and case reads. This matters to the procurement decision: an API capability described in documentation would be insufficient if the organisation could not use it under the actual account arrangement.

Decide whether the journey can accommodate waiting

The business owner confirms that the initial customer acknowledgement may state that the request has entered processing, provided the final case reference is not claimed until creation is confirmed. The interface can therefore distinguish a pending operation from a completed business record.

The selected scope keeps OP-17 as an operational correlation reference. It presents a clear pending state and retrieves the result through the supported read-back. Once C-91 is confirmed, the customer-facing case reference is drawn from that business record. The project also needs a defined owner and communication path for a terminal failure.

If the organisation required a final case number in the immediate response with no pending stage, this provider contract would not satisfy that requirement as inspected. The procurement choice depends on the real customer journey, not on whether a demonstration can display any identifier quickly.

Complete the evidence for the choice

In the accepted fictional fixture, one create request starts OP-17. While processing remains pending, no final case number is displayed. The later completed status resolves to C-91, and the read-back confirms that C-91 contains the intended enquiry context.

The request log shows no repeated create operation used to obtain that result. Status checks are reads under the documented contract. A terminal-failure comparison produces no claimed case number and enters the agreed staff-resolution route.

An unknown operation reference is also handled as unresolved. The application does not interpret an empty or inaccessible status response as successful creation. The accepted scope records how long an unresolved operation is observed and when responsibility passes to the designated operator; it does not invent a provider completion guarantee.

Turn the finding into a proposal requirement

The team selects the provider for this defined journey with the pending state, authorised read-back and failure ownership included. Those are part of the integration work, not optional polish around a simple form submission. The proposal names the dependency on the provider’s actual contract and account permissions.

For another project, ask the same concrete questions: what does each identifier represent, what proves the business record exists, what can fail later and who resolves it? The integration service can help inspect those boundaries. A useful reference tells the recipient which record they have, rather than disguising an unfinished operation as a completed case.