📝 Send pre-signed raw Bitcoin transaction

Code samples

POST /api/v1/btc/transactions/send-raw

curl -X POST 'https://settla.net/api/v1/btc/transactions/send-raw' \
  -H 'X-API-Key: $SETTLA_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
  "rawTransaction": "01000000000101bbe899bde41927e0a22fd11e7ef3149c8919632f242d7f84250c8380b2f83bd80000000000ffffffff02804f120000000000160014e93523416d7137dad7b63813ca2a72010bc94d3b400d030000000000160014…"
}'

Broadcasts a signed, hex-encoded transaction via sendrawtransaction. Signing happens entirely on your side — the platform never sees a private key. Build and sign the transaction in your own wallet, then post the raw hex here. Both rawTransaction and signedTransaction are accepted; they are aliases for the same field, and rawTransaction is the documented name. On success you get the txid back, which means the node accepted the transaction into its mempool — not that it is confirmed. Poll GET /api/v1/btc/transactions/{hash} and watch confirmations. A rejected transaction — bad signature, insufficient fee, already-spent input — surfaces as 500 with the generic Could not connect to BTC node. message, so you cannot tell rejection from an outage by the response alone. To find out why before broadcasting, send testmempoolaccept through the JSON-RPC proxy: it returns the node's actual reject reason.

Body parameter

{
  "rawTransaction": "01000000000101bbe899bde41927e0a22fd11e7ef3149c8919632f242d7f84250c8380b2f83bd80000000000ffffffff02804f120000000000160014e93523416d7137dad7b63813ca2a72010bc94d3b400d030000000000160014…"
}

🛠️ Parameters

Name	In	Type	Required	Description
body	body	object	true	none
» rawTransaction	body	string	true	Signed transaction, hex-encoded, no `0x` prefix. This is exactly the `hex` field you get back from `GET /api/v1/btc/transactions/{hash}`.
» signedTransaction	body	string	false	Alias of `rawTransaction`. Send one or the other, not both.

Example responses

200 Response

{
  "transactionHash": "5fc111d07140a808ba08ac28f61fd436efbfe9d84f5437abe980b42c8d9f0a5e"
}

422 Response

{
  "error": "Field \"rawTransaction\" is required and must be a string"
}

500 Response

{
  "error": "Could not connect to BTC node."
}

🔁 Responses

Status	Meaning	Description	Schema
200	OK	Node accepted the transaction into its mempool. Not a confirmation.	Inline
422	Unprocessable Entity	`rawTransaction`/`signedTransaction` missing, or not a string. The request never reached the node.	Inline
500	Internal Server Error	Node unreachable or the transaction was rejected — the two are indistinguishable here. Common rejection causes: an input already spent (`txn-already-known`, `bad-txns-inputs-missingorspent`), a fee below the node's minimum relay fee, a bad signature. Run `testmempoolaccept` through the JSON-RPC proxy first if you need the real reason.	Inline

🔄 Response Schema

Status Code 200

Name	Type	Required	Restrictions	Description
» transactionHash	string	false	none	txid of the broadcast transaction. Matches the txid you computed locally when signing — if it does not, the node malleated nothing and you serialised something else.

Status Code 422

Name	Type	Required	Restrictions	Description
» error	string	false	none	Human-readable reason.

Status Code 500

Name	Type	Required	Restrictions	Description
» error	string	false	none	Human-readable reason.