| Time | Status | User Agent | |
|---|---|---|---|
Retrieving recent requests… | |||
Get Reserve Funding Request Status
GET /api/v1/reserve-funding/requests/{externalRequestId}
Reads the current state of a previously submitted reserve funding request. This is the reconciliation path — the only authoritative source of status. The decision callback (sent when a Netevia employee approves or rejects a request) is best-effort and may never arrive, so this endpoint is worth polling on a schedule regardless of whether you also receive callbacks.
Use this together with POST /api/v1/reserve-funding/requests, which creates the request this endpoint reads back.
Authentication
Basic HTTP authentication. Requires the same Reserve Funding API access permission and manage-reserve-funding-requests module as the submit endpoint, otherwise 403.
Path parameter
| Parameter | Type | Required | Notes |
|---|---|---|---|
externalRequestId | string | Required | The reference you supplied on submit. Trimmed before lookup, but not otherwise normalized. URL-encode it if it contains anything outside A–Z a–z 0–9 - _ .. |
Scoping
You can only read requests submitted by your own API user. A request submitted by a different integrator returns 404, exactly like an unknown reference — an unknown id and someone else's id are deliberately indistinguishable, so a 404 does not by itself confirm the reference was never submitted at all.
Response
200 — Pending
200 — Pending{
"data": {
"internalRequestId": "HQ-RF-REQ-101",
"externalRequestId": "RF-2026-09-0001",
"status": "Pending"
},
"requestId": 407190,
"success": true
}200 — Approved, downstream not yet finished
200 — Approved, downstream not yet finished{
"data": {
"internalRequestId": "HQ-RF-REQ-102",
"externalRequestId": "RF-2026-09-0002",
"status": "Approved",
"processedBy": "Maxim Rikhm",
"processedAt": "2026-09-11T12:08:49Z"
},
"requestId": 407191,
"success": true
}200 — Approved, with processing result
200 — Approved, with processing result{
"data": {
"internalRequestId": "HQ-RF-REQ-102",
"externalRequestId": "RF-2026-09-0002",
"status": "Approved",
"processedBy": "Maxim Rikhm",
"processedAt": "2026-09-11T12:08:49Z",
"processingResult": { "status": "Success", "errorCode": null, "message": null }
},
"requestId": 407192,
"success": true
}200 — Rejected
200 — Rejected{
"data": {
"internalRequestId": "HQ-RF-REQ-103",
"externalRequestId": "RF-2026-09-0003",
"status": "Rejected",
"processedBy": "Maxim Rikhm",
"processedAt": "2026-09-11T12:08:43Z",
"comment": "Signed agreement does not match the requested ceiling."
},
"requestId": 407193,
"success": true
}Response fields
Decision fields are absent, not null, while a request is still pending.
| Field | Present when | Meaning |
|---|---|---|
internalRequestId | Always | The same HQ-RF-REQ-<n> returned by the POST and carried by the decision callback. Identical across all three. |
status | Always | Pending, Approved, or Rejected. Terminal once decided — a rejected request is never reopened; recovering means submitting a new request under a new externalRequestId. |
processedBy | After a decision | Full name of the Netevia reviewer who decided. |
processedAt | After a decision | ISO-8601 timestamp in UTC (trailing Z). Compare against UTC, not local time. |
comment | Rejected only | The reviewer's free-text reason, up to 1024 characters. Mandatory on the Netevia side, so a rejection always carries one. |
processingResult | Approved only, and only once downstream has run | Whether the reserve was actually created after approval. Absent until downstream processing finishes — a freshly approved request can briefly return Approved with no processingResult at all. |
processingResult
processingResultstatus is Success or Failed.
- On success:
errorCodeandmessageare bothnull. - On failure:
errorCodeisSETTINGS_CREATION_FAILEDandmessageis"Failed to create Reserve Funding Settings in merchant profile."
An Approved status alone does not mean the reserve was created — check processingResult. A Failed result means the decision stands but nothing was created; this needs a call to Netevia, quoting internalRequestId. A common underlying cause is a mismatch between the funding department's bank and the merchant's bank, which is not checked at submit time.
404 — Unknown reference
404 — Unknown reference{
"requestId": 407185,
"success": false,
"error": "Reserve funding request not found."
}Three usual causes:
- The reference doesn't match character-for-character (it's trimmed, but not otherwise normalized).
- It contains characters outside
A–Z a–z 0–9 - _ .and wasn't URL-encoded. - It was submitted by a different API user — see Scoping above.
Recommended usage
Poll this endpoint on a schedule rather than relying solely on the decision callback: the callback is delivered best-effort (an initial attempt plus one requeue), and a decision is never rolled back because a callback failed to arrive. If your callback endpoint was briefly down, this is the only way to learn what happened.
OpenAPI definition
{
"openapi": "3.0.0",
"info": {
"version": "v1",
"title": "Netevia HQ | API Documentation",
"description": "Netevia HQ | API Documentation"
},
"paths": {
"/api/v1/reserve-funding/requests/{externalRequestId}": {
"get": {
"tags": ["ReserveFundingApi"],
"summary": "Get Reserve Funding Request Status",
"operationId": "ReserveFundingApi_GetReserveFundingRequestStatus",
"parameters": [
{
"name": "externalRequestId",
"in": "path",
"description": "The external service's unique request id",
"required": true,
"schema": { "type": "string" }
}
],
"responses": {
"200": {
"description": "OK",
"content": {
"application/json": { "schema": { "type": "object" } },
"text/json": { "schema": { "type": "object" } },
"application/xml": { "schema": { "type": "object" } },
"text/xml": { "schema": { "type": "object" } }
}
}
}
}
}
},
"security": [{ "Basic": [] }],
"servers": [{ "url": "https://hq.staging.netevia.dev" }],
"components": {
"securitySchemes": {
"Basic": { "type": "http", "description": "Basic HTTP Authentication", "scheme": "basic" }
}
}
}