Funding
Generated HTTP reference for the 1 operation the published OpenAPI document describes under funding.
2 min read
Funding
This page is generated from the published OpenAPI document. It is complete with respect to that document and says nothing about surfaces the document does not describe yet. See what is generated here for what that means.
Base URL: https://api.codespar.dev
Every operation below requires a Bearer token. See Authentication.
GET /v1/consumers/{consumerId}/fund/{txId}
GET
https://api.codespar.dev/v1/consumers/{consumerId}/fund/{txId}Poll an onramp, and credit the wallet when it settles
Path parameters
| Name | Type | Required | Description |
|---|---|---|---|
consumerId | string | yes | — |
txId | string | yes | The ramp provider's transaction id, from the fund call. |
Responses
| Status | Body | Description |
|---|---|---|
200 | object | OK |
404 | object | One code, and THREE distinct failures collapse into it. The route answers 404 exactly when the provider lookup yields nothing, and that lookup gives up in three separate places: 1. NOT CONNECTED. The organization has no ramp-provider account in connected state. A caller that never completed the provider connection sees this on every poll, for every transaction id. 2. CREDENTIAL GONE. The connection row exists and still reads as connected, but its stored credential no longer dereferences: revoked, rotated, or vaulted under a scope that no longer matches the row. Nothing else about the connection looks broken, which is what makes this one hard to recognize from the outside. 3. THE PROVIDER DID NOT RETURN IT. Any non-2xx from the provider lands here. That covers both this credential has no such transaction and the provider is down or refused, and the two are NOT distinguished: an outage is indistinguishable from an unknown id at this boundary. Only the third is worth retrying, and the response does not say which one happened. So read a 404 as this API cannot currently see the transaction, never as the transaction does not exist, and in particular never as grounds for starting a second onramp for the same deposit. |
Response 200
| Field | Type | Required | Description |
|---|---|---|---|
amount_minor | integer | yes | USDC the wallet receives, in minor units. Only meaningful once the tx settles. |
credited | boolean | yes | True whenever this poll found the transaction in a terminal success state with a positive delivered amount, and therefore posted the ledger credit. It is true on EVERY such poll, not only the first: the credit deduplicates on a deterministic external reference derived from the transaction id, so the repeat post is a no-op. Read it as this transaction has settled and the credit exists, never as this call created the credit. |
currency | string | yes | — |
status | string | yes | The ramp provider's status, lower-cased and passed through (awaiting_deposit, processing, completed, and others it may add). Not a closed set. |
transaction_id | string | yes | Echoes the path parameter. |
Example request
curl -X GET https://api.codespar.dev/v1/consumers/{consumerId}/fund/{txId} \
-H "Authorization: Bearer $CODESPAR_API_KEY"const res = await fetch("https://api.codespar.dev/v1/consumers/{consumerId}/fund/{txId}", {
method: "GET",
headers: {
Authorization: `Bearer ${process.env.CODESPAR_API_KEY}`,
},
});
const data = await res.json();Example response 200
{
"transaction_id": "transaction_0000000000000000",
"status": "string",
"amount_minor": 1000,
"currency": "BRL",
"credited": true
}