Proxy a PATCH request to the Verification API

Forwards a PATCH request to the underlying Verification API (https://api.verification.flutterwave.com) on behalf of the authenticated caller, injecting the internal Verification API secret key server-side so callers never see or supply it themselves.

downstreamPath is a catch-all path segment — it can contain slashes — representing the path on the Verification API to call (for example v1/verifications/bvn/01HQZR2BKPFQ or v1/banks/ng/044). It is checked against an explicit allow-list before any upstream call is made: once leading slashes are stripped, it must start with v1/verifications or v1/banks. Any other path (for example anything under /admin/*) is rejected with a 400 and never reaches the Verification API.

Any JSON object supplied as the request body, and any query string parameters, are forwarded to the downstream Verification API verbatim — this proxy does not add, remove, or validate individual fields beyond confirming the body (if present) is an object. The exact fields accepted depend entirely on which downstream Verification API path is being called; consult the Verification API's own documentation for the specific path you are proxying to.

On a successful upstream call, this endpoint returns the downstream Verification API's HTTP status code and response body unmodified as data — it does not re-shape or validate the downstream payload. Critically, this pass-through also applies when the Verification API itself responds with a 4xx/5xx status for the given path: from this proxy's perspective that is not a proxy failure, so the HTTP status code on the response mirrors whatever the Verification API returned (which may itself be an error status), while the response envelope's status field still reads success and data holds the Verification API's raw (possibly error-shaped) body. Only a rejected path, a request validation failure, or a genuine network/timeout failure while calling the Verification API produce this proxy's own error-status envelope.

Every attempted call — allowed, rejected, or failed — is recorded in a PII-free audit log (caller identity, HTTP method, downstream path, upstream status code, outcome, and duration). Audit logging is best-effort and never blocks or fails the response back to the caller.

Request

Authorization

JWT Bearer

Add the parameter

Authorization

to Headers

Example:

Authorization: ********************

Bearer Token

Provide your bearer token in the

Authorization

header when making requests to protected resources.

Example:

Authorization: Bearer ********************

Path Params

Body Params application/json

Examples

Responses

🟢200

application/json

The Verification API accepted the proxied PATCH request. data is the downstream response body, returned unmodified. Note that the HTTP status code on this response is whatever the Verification API returned for this specific call, which is not necessarily 200 — it may also be a 4xx/5xx status that the Verification API itself produced for the given downstream path, since those are passed through rather than treated as proxy failures.

Bodyapplication/json

🟠400

🟠401

🔴500