Bitcoin broadcast transaction API to push raw transactions

The request body is {"hex": "<signed raw transaction>"}. An accepted transaction comes back as HTTP 201 with the txid, the status "in mempool" and a link to GET /v1/tx/{txid}, so the next call your code makes is the confirmation check. A transaction the network turns down comes back as HTTP 422 with the code rejected_by_network and a field called network_said that carries the node's own reason, word for word. A relay that cannot be reached comes back as HTTP 503 with index_unavailable. Those three outcomes are kept apart on purpose, because the most expensive broadcast bug is treating one of them as another.

Here is why that matters, measured on 25 September 2026. We took a transaction that had already confirmed, 311ca5e1759b6a2a9d512210729b63445d784962b3f4d3825d03a0d8ff6ee920 in block 968,537, and posted its raw hex again to three public broadcast endpoints with the chain tip at 968,542. mempool.space and Blockstream Esplora both answered HTTP 400 with Bitcoin Core's RPC error -27, "Transaction outputs already in utxo set". BlockCypher answered HTTP 400 with "Transaction with hash ... already exists". Then we posted 80 bytes of zeros, which is not a transaction at all. mempool.space and Esplora answered HTTP 400 with RPC error -22, "TX decode failed". BlockCypher answered HTTP 400 with "insufficient priority and fee for relay", which describes a fee problem the payload does not have.

So on all three services, a payment that already succeeded and a payload that was never a transaction return the same status code. Retry logic that reads only the status sees "failed" in both cases. The dangerous version rebuilds the payment with fresh inputs and sends it again, and a customer is paid twice. The safe rule is short: on any rejection, look up the txid you computed before broadcasting. If it is already in a block or in the mempool, the payment went through and the rejection is noise. If it is not, read the node's reason and fix that.

This API gives you both halves in one place. The broadcast answer carries the node's reason verbatim, and GET /v1/tx/{txid} on the same key tells you whether the transaction is in the mempool or which block confirmed it. Obvious mistakes are answered before the network is called at all: a body that is not hex, an odd number of characters, fewer than 60 bytes, or more than 200 kB returns HTTP 400 invalid_hex instantly. A broadcast costs one API credit, and the Developer plan at $49 a month includes 500,000.

Two honest limits. We relay each transaction through one Bitcoin Core backed node rather than fanning it out to dozens of peers, so if you need maximum propagation for a low-fee transaction, also submit it to a second service; broadcasting the same valid transaction twice is harmless. And signing stays entirely on your side: this endpoint never builds, signs, holds or stores a key.