Jump to: , Contents 1 2 3 4 5 6 7 8 9 C Run bitcoind or bitcoin-qt -server.You can control it via the command-line bitcoin-cli utility or by HTTP JSON-RPC commands.You must create a bitcoin.conf configuration file setting an rpcuser and rpcpassword; see Running Bitcoin for details.A list of RPC calls will be shown.If you are learning the API, it is a very good idea to use the test network (run bitcoind -testnet and bitcoin-cli -testnet).Running Bitcoin with the -server argument (or running bitcoind) tells it to function as a HTTP JSON-RPC server, but Basic access authentication must be used when communicating with it, and, for security, by default, the server only accepts connections from other processes on the same machine.If your HTTP or JSON library requires you to specify which 'realm' is authenticated, use 'jsonrpc'.Bitcoin supports SSL (https) JSON-RPC connections beginning with version 0.3.14.See the rpcssl wiki page for setup instructions and a list of all bitcoin.conf configuration options.

Allowing arbitrary machines to access the JSON-RPC port (using the rpcallowip configuration option) is dangerous and strongly discouraged-- access should be strictly limited to trusted machines.litecoin mining testTo access the server you should find a suitable library for your language.bitcoin calculator javaSee the proper money handling page for notes on avoiding rounding errors when handling bitcoin values.linux uninstall bitcoinpython-jsonrpc is the official JSON-RPC implementation for Python.bitcoin kurs downloadIt automatically generates Python methods for RPC calls.bitcoin tcl

However, due to its design for supporting old versions of Python, it is also rather inefficient.jgarzik has forked it as Python-BitcoinRPC and optimized it for current versions.ethereum case studyGenerally, this version is recommended.While BitcoinRPC lacks a few obscure features from jsonrpc, software using only the ServiceProxy class can be written the same to work with either version the user might choose to install: The latest version of python-bitcoinrpc has a new syntax.By default the client will use the configuration in $HOME/.bitcoin/bitcoin.conf or you can instead specify a URI like this: Here is a usage example: The JSON-RPC PHP library also makes it very easy to connect to Bitcoin.For example: Note: The jsonRPCClient library uses fopen() and will throw an exception saying "Unable to connect" if it receives a 404 or 500 error from bitcoind.This prevents you from being able to see error messages generated by bitcoind (as they are sent with status 404 or 500).

The EasyBitcoin-PHP library is similar in function to JSON-RPC PHP but does not have this issue.The easiest way to tell Java to use HTTP Basic authentication is to set a default Authenticator: Once that is done, any JSON-RPC library for Java (or ordinary URL POSTs) may be used to communicate with the Bitcoin server.Instead of writing your own implementation, consider using one of the existing wrappers like BitcoindClient4J, btcd-cli4j or Bitcoin-JSON-RPC-Client instead.The JSON::RPC package from CPAN can be used to communicate with Bitcoin.You must set the client's credentials; for example: The btcrpcclient package can be used to communicate with Bitcoin.You must provide credentials to match the client you are communicating with.The communication with the RPC service can be achieved using the standard http request/response objects.A library for serializing and deserializing Json will make your life a lot easier: /json ) is a high performance JSON package for .NET.It is also available via NuGet from the package manager console ( Install-Package Newtonsoft.Json ).

The following example uses Json.NET: There is also a wrapper for Json.NET called Bitnet (https://sourceforge.net/projects/bitnet) implementing Bitcoin API in more convenient way: /GeorgeKimionis/BitcoinLib) which is also available via NuGet from the package manager console (Install-Package BitcoinLib).Querying the daemon with BitcoinLib is as simple as: You can also send commands and see results using cURL or some other command-line HTTP-fetching utility; for example: You will be prompted for your rpcpassword, and then will see something like: clj-btc is a Clojure wrapper for the bitcoin API.The C API for processing JSON is Jansson.C applications like libblkmaker use cURL for making the calls and Jansson for interpreting the JSON that cURL fetches.For example basic usage (which can be easily modified for Bitcoin RPC), see the Jansson example github_commits.c and the associated tutorial.The following does with libcurl what the does:This output can be parsed with Jansson, the Jansson tutorial linked to above.

QJsonRpc is a Qt/C++ implementation of the JSON-RPC protocol.It integrates nicely with Qt, leveraging Qt's meta object system in order to provide services over the JSON-RPC protocol.QJsonRpc is licensed under the LGPLv2.1.Welcome to BlockCypher’s API documentation!Currently, BlockCypher supports Bitcoin, Ethereum, Litecoin, Dogecoin, Bitcoin Testnet3, and BlockCypher’s Test Chain (more about BlockCypher’s Test Chain below).BlockCypher’s API provides a superset of the endpoints you’d find in reference implementations, in addition to some special features that make BlockCypher uniquely powerful, like our unconfirmed transaction Confidence Factor, dependable WebHook or WebSockets-based Events, On-Chain Microtransactions, and Payment Forwarding.Consequently, if you’re familiar with a blockchain’s reference implementation, you’ll feel at home using BlockCypher, but without worrying about scaling or implementation challenges.And if you’re not familiar—with the reference implementations or blockchains in general—BlockCypher’s API is a great way to dip your toes into blockchain development, without a lengthy setup process.

In either case, BlockCypher has 99.99% up-time, and maintains an expressive, logical API that you’ll love.In these docs you’ll find everything you need to leverage BlockCypher for your applications.For all officially supported languages, you’ll see code samples, in addition to basic cURL requests/responses for every endpoint.You can switch between cURL/language samples via the selector in the upper right.We’re working on supporting more languages, but if you’re working on your own language library, definitely let us know: we’d love to add more community supported libraries here.We know many learn more from code examples than specific reference documentation, which is why we have code samples in our official languages.In addition, we have a number of in-browser code examples for particular use cases, which you can see here: Our documentation is powered by GitHub Pages and Slate, which makes viewing changes as simple as checking the git commit history.If there’s an error or you’d like to suggest a change, please consider submitting a pull request to benefit the broader BlockCypher community.

All API calls are versioned, and the current BlockCypher API is v1.We will never introduce any breaking changes within v1, but we may add new, non-breaking features from time to time.BlockCypher has client SDKs for the following languages: If you’re using these languages, we strongly encourage you to use an official SDK.Of course, all our API calls are standard HTTP endpoints using JSON formatted responses, so any language (or cURL from the command-line) will work just fine.This client SDK was made by the community, and is not officially supported by BlockCypher.As such, BlockCypher cannot guarantee that it’s fully up to date, but we hope it will provide a nice jumping-off point for developers using this language.We’ll endeavor to keep this list updated, if any of these prove obsolete.If there’s enough support for a particular language, we’ll work with the community to turn it into an officially supported SDK.Almost all resources exist under a given blockchain, and follow this pattern: Currently, there’s only one version of the API (v1).

Thus, here’s an exhaustive list of blockchains and their corresponding resources: We want everyone to try BlockCypher with as little friction as possible, which is why you don’t need a token for any read-only GET calls.Please register for a user token if you want to use POST and DELETE calls.Once you have your token, you can append it to all your requests like any other URL parameter if you’re using cURL, or through the appropriate method in the language SDK you’re using.We do rate-limit our free tier, with or without a token (though tokens are required for Confidence lookups, WebHooks/Sockets, Payments, and any POST or DELETE calls): The hourly rate limits reset on the top of the hour UTC.For example, if you’re under the free tier, and you have used 200 regular requests by 03:58 UTC, you’ll hit a rate limit until it resets at 04:00 UTC.On the accounts page, you’ll find paid plans starting at $75 a month (with a 10% discount if you pay with Bitcoin).To request higher limits or SLAs beyond what’s offered on the accounts page, please email us.

You can check your current limits and usage via a GET on the following endpoint, outside of our normal coin/chain pattern: Within that return object, you’ll also find hits_history array, which shows your token’s last 48 hours of usage, while hits shows the current hour’s usage.You can even see information about your remaining limits by checking the X-Ratelimit-Remaining attribute in the HTTP header in normal API calls.Keep in mind the X-Ratelimit-Remaining attribute corresponds to the hourly rate limit associated with the endpoint you call (e.g., if it’s from a WebHook, that corresponds to the Hooks/Hour; if it’s a normal call, the number corresponds to the normal Requests/Hour limit).All endpoints that can retrieve a single Object can be batched to return multiple objects.If you’re cURLing the API directly, batching simply requires appending each identifier to the previous one using a semicolon (check the code pane for an example).The results are aggregated in a JSON array.

The other supported client SDKs batch differently, but each idiomatic to their respective language (check the code pane examples in each library).When cURLing BlockCypher, batching also works when the identifiers aren’t the last part of the URL; e.g., this URL will return the balances of three separate addresses: We offer two different options for testing your blockchain application: Bitcoin Testnet3, and BlockCypher’s Test Chain.We offer automated faucets for both Testnet3 and BlockCypher’s Test Chain, but we recommend using BlockCypher’s Test Chain for a variety of reasons: In case you missed the Resources section, the BlockCypher Test Chain is accessible from this resource: To help facilitate automated testing in your applications, a faucet endpoint is available on both BlockCypher’s Test Chain and Bitcoin Testnet3.Calling the faucet endpoint, along with passing a valid address, will automatically create—and propagate—a new transaction funding the address with the amount you provide.

This example shows how to leverage the faucet to programmatically fund addresses, to test your applications.While the example used BlockCypher’s Test Chain, the same example could have used Bitcoin Testnet3 and worked the exact same way.Before diving into BlockCypher’s endpoints, this section details all the Objects exposed and expected by the API.Some of you might be more interested in the endpoints themselves, in which case, feel free to skip to the next section.But for others, a section dedicated to all of BlockCypher’s Objects might prove a useful overview, especially if you’re new to Blockchain development in general.And in either case, this section provides a comprehensive reference for Objects in the API.For each Object there’s a description and a link to a germane API endpoint.A Blockchain represents the current state of a particular blockchain from the Coin/Chain resources that BlockCypher supports.Typically returned from the Chain API endpoint.A Block represents the current state of a particular block from a Blockchain.

Typically returned from the Block Hash and Block Height endpoints.A TX represents the current state of a particular transaction from either a Block within a Blockchain, or an unconfirmed transaction that has yet to be included in a Block.Typically returned from the Unconfirmed Transactions and Transaction Hash endpoints.A TXInput represents an input consumed within a transaction.Typically found within an array in a TX.In most cases, TXInputs are from previous UTXOs, with the most prominent exceptions being attempted double-spend and coinbase inputs.A TXOutput represents an output created by a transaction.A TXConfidence represents information about the confidence that an unconfirmed transaction will make it into the next block.Typically used as a return object from the Transaction Confidence Endpoint.A TXRef object represents summarized data about a transaction input or output.Typically found in an array within an Address object, which is usually returned from the standard Address Endpoint.

A TXSkeleton is a convenience/wrapper Object that’s used primarily when Creating Transactions through the New and Send endpoints.A NullData Object is used exclusively by our Data Endpoint to embed small pieces of data on the blockchain.If your data is over 40 bytes, it cannot be embedded into the blockchain and will return an error A MicroTX represents a streamlined—and typically much lower value—microtransaction, one which BlockCypher can sign for you if you send your private key.MicroTXs can also be signed on the client-side without ever sending your private key.You’ll find these objects used in the Microtransaction API.An Address represents a public address on a blockchain, and contains information about the state of balances and transactions related to this address.Typically returned from the Address Balance, Address, and Address Full Endpoint.An AddressKeychain represents an associated collection of public and private keys alongside their respective public address.Generally returned and used with the Generate Address Endpoint.

A Wallet contains a list of addresses associated by its name and the user’s token.It can be used interchangeably with all the Address API endpoints, and in many places that require addresses, like when Creating Transactions.The name of a wallet must be 1-25 characters long and cannot start with any characters that start an address for the currency contained in the wallet.For example, bitcoin wallet names cannot start with ‘1’ or '3’.An HDWallet contains addresses derived from a single seed.Like normal wallets, it can be used interchangeably with all the Address API endpoints, and in many places that require addresses, like when Creating Transactions.For example, bitcoin wallet names cannot start with '1’ or '3’.An array of HDChains are included in every HDWallet and returned from the Get Wallet, Get Wallet Addresses and Derive Address in Wallet endpoints.An HD Address object contains an address and its BIP32 HD path (location of the address in the HD tree).It also contains the hex-encoded public key when returned from the Derive Address in Wallet endpoint.

An OAPIssue represents a request for either issuance or transfer of new assets, as detailed in the Asset API.An OAPTX represents an Open Assets Protocol transaction, generated when issuing or transfering assets.An Event represents a WebHooks or WebSockets-based notification request, as detailed in the Events & Hooks section of the documentation.A PaymentForward object represents a request set up through the Payment Forwarding service.A PaymentForwardCallback object represents the payload delivered to the optional callback_url in a PaymentForward request.A Job represents an analytics query set up through the Analytics API.A JobArgs represents the query parameters of a particular analytics job, used when Creating an Analytics Job and returned within a Job.Note that the required and optional arguments can change depending on the engine you’re using; for more specifics check the Analytics Engine and Parameters section.A JobResults represents the result of a particular analytics job, returned from Get Analytics Job Results.

Note that the results field will depend largely on the engine used.The first component—and highest level—of the BlockCypher API allows you to query general information about blockchain and blocks based on the coin/chain resource you’ve selected for your endpoints.If you’re new to blockchains, you can think of the blockchain itself as an immutable, distributed ledger.Each block in the blockchain is like a “page” in the ledger containing information about transactions between parties.A great place to start understanding the mechanics behind blockchains is the original Bitcoin whitepaper.General information about a blockchain is available by GET-ing the base resource.The returned object contains a litany of information about the blockchain, including its height, the time/hash of the latest block, and more.For more detailed information about the data returned, check the Blockchain object.If you want more data on a particular block, you can use the Block Hash endpoint.BLOCK_HASH is a string representing the hash of the block you’re interested in querying, for example: The returned object contains information about the block, including its height, the total amount of satoshis transacted within it, the number of transactions in it, transaction hashes listed in the canonical order in which they appear in the block, and more.

For more detail on the data returned, check the Block object.You can also query for information on a block using its height, using the same resource but with a different variable type.BLOCK_HEIGHT is an integer representing the height of the block you’re interested in querying, for example: As above, the returned object contains information about the block, including its hash, the total amount of satoshis transacted within it, the number of transactions in it, transaction hashes listed in the canonical order in which they appear in the block, and more.If you’re curious about the adoption of upgrade features on a blockchain, you can use this endpoint to get some information about its state on the network.Generally speaking, for bitcoin, this will follow the form of tracking bipXX (where XX = a number), but the list of features we’re tracking is always changing.BlockCypher’s Address API allows you to look up information about public addresses on the blockchain, generate single-use, low-value key pairs with corresponding addresses, help generate multisig addresses, and collect multiple addresses into a single shortcut for address viewing, all based on the coin/chain resource you’ve selected for your endpoints.

If you’re new to blockchains, you can think of public addresses as similar to bank account numbers in a traditional ledger.The biggest differences: The Address Balance Endpoint is the simplest—and fastest—method to get a subset of information on a public address.ADDRESS is a string representing the public address (or wallet/HD wallet name) you’re interested in querying, for example: The returned object contains information about the address, including its balance in satoshis and the number of transactions associated with it.The endpoint omits any detailed transaction information, but if that isn’t required by your application, then it’s the fastest and preferred way to get public address information.The default Address Endpoint strikes a balance between speed of response and data on Addresses.It returns more information about an address’ transactions than the Address Balance Endpoint but doesn’t return full transaction information (like the Address Full Endpoint).

ADDRESS is a string representing the public address (or wallet/HD wallet name) you’re interested in querying, for example: The returned object contains information about the address, including its balance in satoshis, the number of transactions associated with it, and transaction inputs/outputs in descending order by block height—and if multiple transaction inputs/outputs associated with this address exist within the same block, by descending block index (position in block).The Address Full Endpoint returns all information available about a particular address, including an array of complete transactions instead of just transaction inputs and outputs.Unfortunately, because of the amount of data returned, it is the slowest of the address endpoints, but it returns the most detailed data record.ADDRESS is a string representing the public address (or wallet/HD wallet name) you’re interested in querying, for example: The returned object contains information about the address, including its balance in satoshis, the number of transactions associated with it, and the corresponding full transaction records in descending order by block height—and if multiple transactions associated with this address exist within the same block, by descending block index (position in block).

The Generate Address endpoint allows you to generate private-public key-pairs along with an associated public address.No information is required with this POST request.The returned object contains a private key in hex-encoded and wif-encoded format, a public key, and a public address.The Generate Multisig Address Endpoint is a convenience method to help you generate multisig addresses from multiple public keys.After supplying a partially filled-out AddressKeychain object (including only an array of hex-encoded public keys and the script type), the returned object includes the computed public address.The Wallet API allows you to group multiple addresses under a single name.It only holds public address information and never requires any private keys.A normal Wallet can be created, deleted, and have addresses added and removed.The Wallet itself can have any custom name as long as it does not start with the standard address prefix (1 or 3 for Bitcoin).We also offer support for HD Wallets, which make it easy to manage multiple addresses under a single name.

All HD wallet addresses are derived from a single seed.Please see BIP32 for more background on HD wallets.HD Wallets can be created, deleted, and have new addresses generated.However, unlike normal Wallets, addresses cannot be removed.When creating a wallet, one can optionally include one or more “subchain” indexes.These subchains can later be referenced when generating new addresses or sending txs.If none are provided in wallet creation, the wallet will derive & use addresses straight from the given extended pubkey.If no index is given when using the wallet with other APIs, it defaults to using the wallet’s first (sub) chain.In BIP32 notation, the wallet layout is m/0, m/1, … and m/i/0, m/i/1, … for each subchain i if the wallet has subchains.For example, the path of the fourth address generated is m/3 for a non-subchain wallet.The path of the fourth address at subchain index two is m/2/3.Note that this is different from the default BIP32 wallet layout.If you want to use BIP32 default wallet layout you can submit the extended public key of m/0’ (which can only be derived from your master private key) with subchain indexes = [0, 1].

Subchain index 0 represents the external chain (of account 0) and will discover all k keypairs that look like: m/0’/0/k.Subchain index 1 represents the internal chain (of account 0) and will discover all k keypairs in m/0’/1/k.If you want to use BIP 44 layout (for BTC), you can submit the extended public key of m/44’/0’/0’.(which can only be derived from your master private key) with subchain indexes = [0, 1].Subchain index 0 represents the external chain (of account 0) and will discover all k keypairs in m/44’/0’/0’/0/k.Subchain index 1 represents the internal chain (of account 0) and will discover all k keypairs in m/44’/0’/0’/1/k.If an address ahead of current addresses listed in an HD Wallet receives a transaction, it will be added, along with any addresses between the new address and the last used one.We limit looking ahead to 20 addresses; if more than 20 addresses are skipped for the next payment to an HD Wallet, it won’t be detected/added to the HD Wallet.

Both HD Wallets and normal Wallets can be leveraged by the Address API, just by using their $NAME instead of $ADDRESS.They can also be used with Events and with the Transaction API.In general, using a wallet instead of an address in an API will have the effect of batching the set of addresses contained in the wallet.The following code examples should be considered serially; that is to say, the results will appear as if each API call were done sequentially.Also, $NAME is a string representing the name of your wallet, for example: As you’ll see in the examples, if you’re using HD Wallets, take care to use the appropriate resource (e.g./wallets/hd instead of /wallets ).This endpoint allows you to create a new wallet, by POSTing a partially filled out Wallet or HDWallet object, depending on the endpoint.For normal wallets, at minimum, you must include the name attribute and at least one public address in the addresses array.For HD wallets, at minimum, you must include the name and the extended_public_key attributes.

The encoding of the key is documented here.You can optionally include subchain_indexes to initialize the wallet with one or more subchains.If not given, the wallet will derive address straight from the given extended pubkey.See BIP32 for more info.If successful, it will return the same Wallet or HDWallet object you requested, appended with your user token.This endpoint returns a string array ($NAMEARRAY) of active wallet names (both normal and HD) under the token you queried.You can then query detailed information on individual wallets (via their names) by leveraging the Get Wallet Endpoint.This endpoint returns a Wallet or HDWallet based on its $NAME.This endpoint allows you to add public addresses to the $NAME wallet, by POSTing a partially filled out Wallet object.You only need to include the additional addresses in a new addresses array in the object.If successful, it will return the newly modified Wallet, including an up-to-date, complete listing of addresses.This endpoint returns a list of the addresses associated with the $NAME wallet.

It returns the addresses in a partially filled out Wallet which you’ll find under the addresses attribute.For HD wallets it returns an HDChain object.This endpoint allows you to delete an $ADDRESS associated with the $NAME wallet.As a reminder, you can batch multiple addresses by appending them with semicolons within the $ADDRESS URL parameter.If successful, it will return an HTTP 204 status code with no return object.This endpoint allows you to generate a new address associated with the $NAME wallet, similar to the Generate Address Endpoint.If successful, it will returned the newly modified Wallet composed with an AddressKeychain.Only works for regular Wallets; for HD Wallets, use the Derive Address endpoint specified below.This endpoint allows you to derive a new address (or multiple addresses) associated with the $NAME HD Wallet.If successful, it will return an HDWallet but only with the newly derived address(es) represented in its chains field to limit the data transmitted; for the full address list after derivation, you can follow up this API call with the Get Wallet Addresses Endpoint.

Only works for HD Wallets; for regular wallets, use the Generate Address in Wallet endpoint specified above.This endpoint deletes the Wallet or HD Wallet with $NAME.BlockCypher’s Transaction API allows you to look up information about unconfirmed transactions, query transactions based on hash, create and propagate your own transactions, including multisignature transactions, and embed data on the blockchain—all based on the coin/chain resource you’ve selected for your endpoints.If you’re new to blockchains, the idea of transactions is relatively self-explanatory.Here’s what’s going on underneath the hood: a transaction takes previous “unspent transaction outputs” (also known as UTXOs) as “transaction inputs” and creates new “locking scripts” on those inputs such that they are “sent” to new addresses (to become new UTXOs).While most of these public addresses are reference points for single private keys that can “unlock” the newly created UTXOs, occasionally they are sent to more exotic addresses through pay-to-script-hash, typically multisignature addresses.

Generally speaking, UTXOs are generated from previous transactions (except for Coinbase inputs).The Transaction Hash Endpoint returns detailed information about a given transaction based on its hash.TXHASH is a string representing the hex-encoded transaction hash you’re interested in querying, for example: The returned object contains detailed information about the transaction, including the value transfered, date received, and a full listing of inputs and outputs.The Unconfirmed Transactions Endpoint returns an array of the latest transactions relayed by nodes in a blockchain that haven’t been included in any blocks.The returned object is an array of transactions that haven’t been included in blocks, arranged in reverse chronological order (latest is first, then older transactions follow).Using BlockCypher’s API, you can push transactions to blockchains one of two ways: In either case, for security reasons, we never take possession of your private keys.We do use private keys with our Microtransaction API, but they are for low-value transactions and we discard them immediately from our servers’ memory.

To use BlockCypher’s two-endpoint transaction creation tool, first you need to provide the input address(es), output address, and value to transfer (in satoshis).Provide this in a partially-filled out TX request object.As you can see from the code example, you only need to provide a single public address within the addresses array of both the input and output of your TX request object.You also need to fill in the value with the amount you’d like to transfer from one address to another.If you’d like, you can even use a Wallet instead of addresses as your input.You just need to use two non-standard fields (your wallet_name and wallet_token) within the inputs array in your transaction, instead of addresses: While this particular usage will differ between client libraries, the result is the same: the addresses within your wallet will be used as the inputs, as if all of them had been placed within the addresses array.As a return object, you’ll receive a TXSkeleton containing a slightly-more complete TX alongside data you need to sign in the tosign array.

You’ll need this object for the next steps of the transaction creation process.For the extra cautious, you can protect yourself from a potential malicious attack on BlockCypher by validating the data we’re asking you to sign.Unfortunately, it’s impossible to do so directly, as pre-signed signature data is hashed twice using SHA256.To get around this, set the includeToSignTx URL flag to true.The optional tosign_tx array will be returned within the TXSkeleton, which you can use in the following way: With your TXSkeleton returned from the New Transaction Endpoint, you now need to use your private key(s) to sign the data provided in the tosign array.Digital signing can be a difficult process, and is where the majority of issues arise when dealing with cryptocurrency transactions.We are working on integrating client-side signing solutions into our libraries to make this process easier.You can read more about signing here.In the mean time, if you want to experiment with client-side signing, consider using our signer tool.

Once you’ve finished signing the tosign array locally, put that (hex-encoded) data into the signatures array of the TXSkeleton.You also need to include the corresponding (hex-encoded) public key(s) in the pubkeys array, in the order of the addresses/inputs provided.Signature and public key order matters, so make sure they are returned in the same order as the inputs you provided.If the transaction was successful, you’ll receive a TXSkeleton with the completed TX (which contains its final hash) and an HTTP Status Code 201.Signing and creating transactions can be one of the trickiest parts of using blockchains in your applications.Consequently, when an error is encountered when Creating Transactions, we send back an HTTP Status Code 400 alongside a descriptive array of errors within the TXSkeleton.While we demonstrated the simplest use of our two-endpoint process to create transactions, you can have finer-grain control by modifying the TX request object before sending to /txs/new.By default, we allow unconfirmed UTXOs as inputs when creating transactions.

If you only want to allow confirmed UTXOs, set the confirmations value in your TX request object to 1.Instead of providing addresses, you can use prev_hash and output_index within the inputs array of your request object, in which case, we’ll use the inputs as provided and not attempt to generate them from a list of addresses.We will compute change and fees the same way.BlockCypher will set the change address to the first transaction input/address listed in the transaction.To redirect this default behavior, you can set an optional change_address field within the TX request object.Fees in cryptocurrencies can be complex.We provide 2 different ways for you to control the fees included in your transactions: is a good resource.For even more control, you can also change the script_type in the outputs of your partially filled TX.You’ll notice this used to powerful effect in the section on Multisig Transactions.These are the possible script types: If you’d prefer to use your own transaction library instead of the recommended path of our two-endpoint transaction generation we’re still happy to help you propagate your raw transactions.

Simply send your raw hex-encoded transaction to this endpoint and we’ll leverage our huge network of nodes to propagate your transaction faster than anywhere else.$TXHEX is a hex-encoded raw representation of your transaction, for example: If it succeeds, you’ll receive a decoded TX object and an HTTP Status Code 201.If you’d like, you can use the decoded transaction hash alongside an Event to track its progress in the network.We also offer the ability to decode raw transactions without sending propagating them to the network; perhaps you want to double-check another client library or confirm that another service is sending proper transactions.$TXHEX is a hex-encoded raw representation of your transaction, for example: If it succeeds, you’ll receive your decoded TX object.Multisignature transactions are made simple by the method described in the Creating Transactions section, but they deserve special mention.In order to use them, you first need to fund a multisignature address.

You use the /txs/new endpoint as before, but instead of the outputs addresses array containing public addresses, it instead contains the public keys associated with the new address.In addition, you must select a script_type of mutlisig-n-of-m, where n and m are numbers (e.g., multisig-2-of-3).The code example demonstrates how the partially filled TX request object would appear.After you’ve set up your request object, you send to /txs/new and receive a partially filled TXSkeleton as before, but with data to sign from the source address.Sign this data and include the public key(s) of the source address—as demonstrated in the Creating Transactions—then send along to the /txs/send endpoint.If it returns with an HTTP Status Code 201, then your multisignature address (via a pay-to-script-hash address) is funded.Once funded, you might want to programmatically spend the money in the address at some point.Here the process is similar, but with the inputs and outputs reversed.As you can see in the code sample, you need to provide the public keys within the inputs addresses array, and the corresponding script_type of multisig-n-of-m (e.g., multisig-2-of-3).

Then you follow the same process of sending to /txs/new and getting an array of data to be signed.Each party can send their signed data individually to /txs/send and we can correlate the signatures to the public keys; once we have enough signatures we’ll propagate the transaction.Or you can send all needed signatures alongside ordered public keys with a single call to /txs/send.If you send all signatures in a single call, and you’re spending inputs locked by a multisig-n-of-m script_type, remember that you’ll need n signatures for every element in the TXSkeleton’s tosign array.For example, let’s say /txs/new returns two elements in the tosign array, corresponding to two multisig-2-of-3 inputs locked by pubkey1, pubkey2, and pubkey3: Then you’d need to return each piece of data signed twice, preserving order between signatures and pubkeys, resulting in four elements for the signatures and pubkeys arrays: Some of the most interesting blockchain applications involve embedding data through null-data (also known as OP_RETURN) output scripts with transactions.

While you can certainly use our guided transaction process and customize your script output, there’s a simpler way: through our Data Endpoint.All you need is the data you want to embed (up to 40 bytes, inclusive) and we’ll handle the rest.In your request object, simply include the data you want to embed.By default, you needn’t set an encoding if your data is hex-encoded (like a hash, the typical use case for null-data).That said, if you want to embed plaintext messages in the blockchain, you can set encoding to string.If successful, the return object will include your original request along with the hash of the transaction containing your data as a null-data output.To view the data output on the blockchain, simply query the transaction via the hash returned, and check the null-data output within the returned transaction.Please keep in mind that it will always be represented by hex-encoding on the blockchain, even if you selected string as your data encoding; to see it as your original plaintext, you have to convert it client-side.

By operating a well-connected node, we collect a lot of information about how transactions propagate; for example, our Confidence Factor relies on this connectivity.With this endpoint, you can leverage our connectivity to get an approximation of a transaction’s location of origin.TXHASH is a string representing the hex-encoded transaction hash you’re interested in querying for propagation information.The return object is described below: You can get a live view of unconfirmed transaction propagation analysis on Bitcoin by connecting to our Transaction Propagation WebSocket, at the following address: As soon as an unconfirmed transaction hits 10 peers, we send the object described above through this WebSocket.For more WebSocket implementation details, check Using WebSockets.In addition to our normal Transaction API, we offer a unique, on-chain microtransaction endpoint that makes it easy to propagate smaller, nearly-instantly guaranteed, more frequent transactions that are still publicly auditable and trusted through their existence on the blockchain.

How can we do what others claim require off-chain, centralized services?We leverage our own infrastructure; in particular, our Confidence Factor.When we reach 98% confidence that a microtransaction will reach the next block (usually ~8 seconds), we guarantee its value and return the completed microtransaction.As of this writing, we haven’t had a single failed mictrotransaction, and we’re improving our confidence data all the time.We also pay for the mining fees for your first 8,000 microtransactions.After which, we automatically optimize fee structure to achieve a balance between guaranteeing confidence it will be in the next block and minimizing cost.If there isn’t enough value in your microtransaction for the fee, we’ll return an error.The endpoint is simple to employ, and uses a slightly pared down transaction object, appropriately called a MicroTX.For low value source addresses and testing, we support directly sending private keys—we’ll construct, sign, and send the transaction for you.

We never store the private key, and remove it from server memory as soon as its used.That said, where your application model supports it and/or when dealing with higher-value source addresses, we encourage you to send public keys and sign the data yourself—a two-step process similar to using /tx/new and /tx/send with normal Transactions.In either case, you use the same endpoint.The request object is a partially filled out MicroTX, whose format differs depending on whether you’re sending a private key or public key for the source address.In either case, there are two options you can set: The simplest way to send a Microtransaction is by using a private key.Within the request object you must include from_private (or the equivalent from_wif), to_address, and value_satoshis.You can read more descriptions about these fields within MicroTX object description, although they should be self-explanatory.The call will hold until the Confidence Factor reaches 98% (usually about 8 seconds).

If successful thereafter, a completed MicroTX object will be returned (which will include the transaction’s hash for future queries), along with an HTTP Status Code 201.If your security/application model allows it, we strongly recommend using public keys instead.Much like creating normal transactions the process requires two endpoint calls; the first is similar to the private key method, but with public keys.E.g., your required object must contain from_pubkey (instead of private keys), to_address, and value_satoshis.After POSTing this to /txs/micro you’ll receive another partially filled out MicroTX object, but one containing a tosign array.You must then sign the data in this array with your locally-stored private key; signing can be a tricky process, but you can use our signer tool as a baseline.Once that data is signed, it must be inserted to a signatures within the previously returned MicroTX object.Then, you send this completed MicroTX to /txs/micro.As with the private key method, the call will hold until the Confidence Factor reaches 98% (usually about 8 seconds).

In general, sending any private key to an outside service is bad security practice.However, security and convenience are often in opposition.In terms of deciding whether passing private keys for microtransactions is a reasonable tradeoff, consider the following: Finally, we only offer the option of passing private keys because we understand that signing on the client side can be difficult, depending on the environment.We hope that by fully understanding the tradeoffs and risks, you’ll make the right choice for your situation.One of the things that makes BlockCypher’s API uniquely powerful is our ability to accurately predict the likelihood of an attempted double-spend succeeding against a transaction; this percentage probability is optionally included within the confidence attribute on any unconfirmed transaction returned by the Transaction Hash Endpoint when using the includeConfidence flag, in addition to the explicit Transaction Confidence Endpoint detailed below.So what does that confidence attribute actually mean?

In simpler terms, if an unconfirmed transaction returns a confidence factor of 99.9%, then our data says there’s a 0.1% chance that an attempted double-spend will succeed.By design, we’re conservative.Even when we return 90% confidence, the likelihood of a successful double-spend is significantly lower than 10%.As you may have gathered from the frequency of links to this feature in these docs, we’re exceptionally proud of the work we’ve done to build this feature and provide it to our users.And that pride extends to our own confidence in our confidence product.We’ve leveraged this product internally on two major features: There are a host of factors that go into our confidence calculation, but you can broadly organize them into two categories.The shape of transactions refers to aspects of transactions that don’t vary with time (time-invariant) in our model.The behavior of transactions refers to aspects of transactions that do vary with time (time-variant) in our model.On the shape side of our model, we ask a number of questions about a transaction: How is it structured?

What are its inputs and outputs?What’s its signature type?Broadly speaking, without knowing anything about the network, does it look like this transaction will be confirmed soon?The behavior part of our model primarily focuses on how a transaction propagates through the network.In order to model this correctly, you need both a great connection to the network and a lot of past data, which we have.As BlockCypher pools resources for many users, we’re always connected to a statistically significant number of nodes on the network—we target anywhere between 10 to 20% of the active nodes on any given blockchain—and offer connections in return.By monitoring transaction propagation, the number of nodes that have received it, and how quickly they received it, we can calculate its probability to be the “winning” transaction at any given point in time, if a double-spend was attempted.(As an aside, you can always see if a double spend was attempted by checking the double_spend and double_spend_tx attributes on an unconfirmed transaction) The result is a robust and reliable metric for judging unconfirmed transaction confidence, especially when used in concert with webhooks and websockets.

Our work here is based on several public research results in addition to our own in-depth follow-up research, which you can read about here.We are constantly improving our confidence model, and we always publish our findings when we do.Our confidence interval is automatically included in any unconfirmed transaction, but you can retrieve it through a specific endpoint too.TXHASH is a string representing the hex-encoded transaction hash you’re interested in querying, for example: The returned TXConfidence object contains the all-important confidence percentage, receive count and more.You can find an unconfirmed transaction hash from our block explorer here.Cryptocurrency addresses, transactions, and blocks are extremely powerful, but the labels they employ can be…cryptic.That’s why we have a Metadata API, allowing both public and private key-value storage against addresses, transactions, and blocks.The Metadata API supports both public and private key-value storage.In both cases, setting metadata requires use of a token (if you haven’t already, you can register for one here).

Public metadata is immutable; once set, it cannot be modified or deleted.If you accidentally set public metadata and need it deleted, contact us.Also, as implied by the name, it’s openly accessible to the whole world—regardless of whether they have a token or not.Consequently, private metadata is associated and only accessible with your user token.The methods for interacting with metadata are outlined below.This endpoint retrieves metadata associated with a given $ADDRESS, $TXHASH, or $BLOCKHASH.This endpoint sets or updates metadata (of the form {“$KEY1:$VALUE1,$KEY2:$VALUE2,…}”) associated with a given $ADDRESS, $TXHASH, or $BLOCKHASH.If another key with the same name already exists under your private metadata store, supplying a new value will replace it.New key-value pairs will be added without replacing prexisting key-value pairs.If successful, it will return an HTTP Status Code 204 with no return object.This endpoint deletes all private metadata associated with a given $ADDRESS, $TXHASH, or $BLOCKHASH and your token.

Blockchains contain a wealth of data, but much of it is inscrutable without arduous effort.Our Analytics API makes uncovering these patterns easy, enabling you to discover insights efficiently and programmatically.The publicly accessible Analytics API is a set of preconfigured tools and pipelines built against our flexible analytics backend.It serves as both a useful tool for one-off analysis and a live demonstration for custom implementations.The API is asynchronous; here’s the high level general workflow: Each engine has its own request parameters—listed below—but all are described in detail on the JobArgs object page.The following engines can power your analytics jobs.The resource below represents the URL you’d POST to create an analytics job based on the engine you’re interested in using, along with the required and optional JobArgs parameters for searching.Returns the list of addresses (along with their associated transaction hashes) and amounts that have paid the target address.

Optionally restricted by only returning value_transfer (in satoshis) transfers and above.Returns the list of addresses (along with their associated transaction hashes) and amounts that have been paid by the target address.Returns the most active limit number of addresses, optionally within a certain bounded time range denoted by start and end.Returns the outputs this address generated within a certain bounded time range denoted by start and end.N-degree address connectivity query.Currently only examines addresses that generate outputs in the same transaction as the target address.Returns transactions relayed by a given source (IP address and port) within the given time range denoted by start and end.Note that the max limit is 1000 for this engine.This creates an analytics job asynchronously, taking in appropriate JobArgs based on the engine as described above.Returns a Job; take special note of the ticket which is the unique identifier you’ll use to get results and query job status.You can check the status of your job with this endpoint, using the ticket returned in the Job object from creating an analytics job.

If it’s finished, it will include a result_path with the URL you can follow to get your results.Returns the results of a ticketed job.The results themselves may be an array of JSON objects or an array of strings, depending on the engine used.Blockchains are about transferring value and ownership, so why can’t that value extend beyond a blockchain’s native token?Thanks to the possibility of embedding arbitrary data through null-data outputs, a blockchain can!However, the act of creating these alternate forms of value—and choosing a format that was universally readable—can be fraught with difficulty.We built our Asset API to simplify that process.Now instead of spelunking through a blockchain’s native transactions and interpreting them yourself, you can utilize this set of APIs to easily issue, check, and transfer assets.This set of endpoints currently leverages the Open Assets Protocol, a simple, robust method of embedding assets across any blockchain that supports null-data outputs.

The endpoints (and code examples) are ordered below to demonstrate how to create asset addresses, issue assets, transfer them, then query the assets/asset addresses you initially created.The Generate Asset Address Endpoint returns a private/public keypair and the associated oap_address (the asset address) and original_address (native address on parent blockchain).Asset addresses are just like regular bitcoin addresses, and are generated from a private-public keypair.They only differ by a prefix (ex: ‘a’ for instead of '1’) to distinguish them.The Issue Asset Endpoint issues new assets onto an OAP to_address, using your private key.Notice that an issuance returns an OAPTX with no inputs, since it is the original issue.The Transfer Asset Endpoint transfers already issued assets (represented by ASSETID) onto a different OAP to_address, using your private key.The List Asset TXs Endpoint returns an array of strings representing transaction hashes associated with this ASSETID.The Get Asset TX Endpoint returns an OAPTX by TXHASH and ASSETID.

The Get Asset Address Endpoint returns an Address representing information about a particular OAPADDR underneath a given ASSETID.Note that while it returns an Address object, anything that would have represented “satoshis” now represents “amount of asset.” (e.g., balance, value, etc.)One of the well-known benefits of cryptocurrency is the ability to allow users to partake in online commerce without necessarily requiring extensive setup barriers, like registering new accounts.In that spirit, our Payment Forwarding API is the easiest way to accept—and consolidate—payments securely without forcing your users to create accounts and jump through unnecessary loops.It’s also a generic way to automatically transfer value from one address to another.While there are many possible use cases, the two we hear most about are: We do not take a fee on payment forwarding, other than the required 10,000 satoshi miner fee; payments are free.However, as part of your own services, you can include a fee (either fixed or a percentage) that will also be automatically transfered to your own address in the same transaction.

Fee-based business models are thus easily achieved, and moreover, easily auditable via the blockchain.First, to create an payment forwarding address, you need to POST a partially filled PaymentForward object to the payment creation endpoint.You need to include at least a destination address and your token; optionally, you can add a callback_url, processing fees (either percent or fixed) and a process_fee_address, and a few other options.You can see more details about these options in the PaymentForward object details.In return, you’ll get a more complete PaymentForward object, including an input_address and id.To list your currently active payment forwarding addresses, you can use this endpoint.This returns the full array of your currently active payment forwarding addresses, based on your token.By default, this endpoint only returns the first 200 payment forwards.If you have more, you can page through them using the optional start parameter.When you’re done with a payment forwarding address, you can delete it via its id.

PAYID is a string representing the payment forwarding request you want to delete, for example: This will return no object, but will return an HTTP Status Code 204 if the request was successfully deleted.Blockchains are highly transactional systems.Many usage patterns require knowing when an event occurs: i.e., when a transaction is included into a block, or when an unconfirmed transaction is relayed through the network.Instead of requiring you to continuously poll resources, we provide push APIs to facilitate those use cases, and support both WebSockets and WebHooks.WebSockets are typically used in client applications when a server is not already running: e.g., a web page displaying the most recent transactions or a wallet app updating its UI when a transaction has been confirmed.Websockets are less reliable in longer interactions (> 1 hour) because they require a connection to stay open.WebHooks are the most reliable way to get event notifications but requires running a server to receive the callbacks.

We automatically retry HTTP requests 5 times.We support a number of different event types, and you can filter your notification requests depending on how you structure your Event request object.Opening a WebSocket to listen to our feeds is easy, like so in Javascript: The code may differ if you’re not programming in Javascript (check relevant code examples for our standard libraries) but the URL will be identical.Once the socket is opened, the JSON document representing the Event of interest should be sent.In addition to standard events, WebSockets accept a “ping” event.If you send the following, you will receive the same message back with “ping” replaced by “pong”: A regular ping (i.e.every 20 seconds) allows the WebSocket to stay connected for a longer period of time.Using the example above, we can demonstrate a client-side WebSocket event stream directly from your browser.In that example, we will subscribe to all pooled transactions (new, unconfirmed transactions) by opening a new WebSocket and sending the filter (unconfirmed-tx).

Upon notification of new transactions, we format them and add them into the page.WebHooks leverage similar objects and interactions but with two key differences: We retry individual payloads to your url five times; if one fails, we wait exponentially between retries: 1 second, 2s, 4s, 8s, 16s.In order to protect against stale callback urls, your Event will be deleted if it reaches 50 aggregate callback_errors from failed payloads.Using a partially filled out Event, you can create a WebHook using this resource.Check the Event object description and types of events to understand the options available for your events.If successful, it will return the Event with a newly generated id.This resource lists your currently active events, according to the base resource and $YOURTOKEN.This resource returns an Event based on its generated id.WEBHOOKID is a string representing the event’s generated id, for example: This resource deletes an active Event based on its id.Remember to include your token, or the request will fail.