API Response

Overview

Context and purpose

The response communicates whether the request was accepted, completed, rejected, redirected, or requires later status retrieval. A successful transport status may not mean final business completion, particularly for queued or asynchronous work. HTTP APIs combine protocol status and headers with an optional body defined by the operation’s schema. Recovery from an API Response failure should begin by determining whether work was rejected, not attempted, executed but unacknowledged, or partially completed. The API Response contract should define identifiers, validation, authorization, status semantics, errors, limits, and version behavior at the same boundary. Clients should validate schemas, handle all documented statuses, respect caching and retry guidance, and reconcile important operations when completion remains uncertain. An API Response is the server’s documented result for a request and may report accepted or pending state rather than final business completion. Providers should align status with semantics, document asynchronous states, include correlation and resource identifiers, and protect sensitive fields.

How it works

An API response communicates what a server knows about a request at a particular moment: an HTTP status, machine-readable body and often an operation identifier. For asynchronous money movement, success of request acceptance does not mean success of the underlying transfer.

Practical checks and failure points

Handle transport failure, validation errors and business-state transitions separately; log safe correlation IDs rather than credentials.

Related concepts

Payment Event Delivery · Idempotency

Further reading

• api-security.owasp.org official reference