Why the free Bitcoin wallet API endpoint is for test keys only
The key pair is generated on a remote server and sent back to you over the network. It is therefore not yours alone. Never put real funds in an address generated this way.
This is not a warning about a hypothetical attacker. A private key created somewhere other than your own machine, and then transmitted, has existed in at least one process memory and one network path you do not control. A secret cannot be un-known. Treat every value the free Bitcoin wallet API endpoint hands back as public from the moment it exists.
Now the useful half. There are real jobs that need key material with correct format and zero value, and this is exactly the tool for them.
Learning. One request shows how a private key, its WIF encoding and a public address relate to each other. Reading about that relationship is slower than seeing three fields arrive together and taking them apart.
Testing wallet code. Parsing, validation, checksum handling and display logic all need input in genuine Bitcoin format. Generate a pair, feed it through your code, throw it away.
Throwaway addresses. Fixtures, screenshots, README samples and API examples all want an address string. Use a generated one instead of borrowing somebody else's real address.
For funds that matter, use a hardware wallet or well-audited local software that generates keys offline on a device you control and never transmits the secret anywhere.
Generate a key pair
No headers, no body, no authentication. The base URL is https://aisenseapi.com/services/v1 for every endpoint in this catalogue.
curl https://aisenseapi.com/services/v1/bitcoin/generate_new_walletThe response has exactly three fields. The values below are placeholders, written to show the shape of each field. They are not a real key pair, and no real generated key is published on this page.
{
"private_key": "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef",
"private_key_wif": "5PLACEHOLDERPLACEHOLDERPLACEHOLDERPLACEHOLDERPLACEH",
"public_address": "1PLACEHOLDERPLACEHOLDERPLACEHOLD"
}Response fields
| Field | Type | Description |
|---|---|---|
| private_key | string | The raw key as 64 hexadecimal characters, which is 32 bytes. This is the entire secret. |
| private_key_wif | string | The same key in Wallet Import Format, the base58 encoding that wallet software accepts on import. |
| public_address | string | The legacy address derived from the key. Begins with the digit 1. |
Each call returns a new pair. Nothing is stored, so a key you discard is gone, and a key you keep is your responsibility.
A quick sanity check on any response: the private key is 64 characters of hexadecimal, the WIF string is 51 characters and starts with the digit 5, and the address starts with the digit 1. If a value in your test suite fails one of those checks, look at your own handling code first, because the shape of the response does not vary.
How the three values relate
- The private key is the whole secret
32 random bytes, shown as 64 hex characters. Everything else in the response is derived from it. Whoever holds it controls whatever the address holds, which is precisely why a key that arrived over a network belongs in a lesson and not in a wallet.
- WIF is the same key, packaged
Wallet Import Format is not a second key. It is the same 32 bytes wrapped in base58 with a version byte and a checksum, so a mistyped character is caught instead of silently importing the wrong key. Most wallet software expects this form when you paste a key in.
- The address is a one-way derivation
The public address comes from the key through hashing and cannot be run backwards to recover it. That asymmetry is why an address is safe to publish or print in a QR code, while the key never is.
One format limit is worth knowing before you build against this. The generator produces legacy P2PKH addresses, the kind beginning with 1. It does not produce bech32 segwit addresses beginning with bc1, and it does not produce taproot addresses. If your code must handle bc1 input, this endpoint will not exercise that path. Curious how the base58 layer under WIF works? The Base58 Encode API endpoint lets you play with the same alphabet directly.
Reading a balance is a separate endpoint
Generation and lookup are two different jobs, so they live on two different pages. To read the confirmed balance of any address in BTC and satoshis, see the Bitcoin Balance API endpoint.
That call carries none of the risk described above. It is read-only, and it takes only an address, which is public information by design. You can safely point it at any address, including one you generated here and including one you own.
Common uses
Several kinds of work suit the free Bitcoin wallet API endpoint well.
Test suite fixtures
Give integration tests a fresh throwaway address each run instead of committing a real one to the repository.
Wallet code under test
Exercise parsing, validation and display against real Bitcoin format and zero value.
Teaching key material
Show a class, in one request, how a private key, its WIF encoding and an address are three views of one thing.
Documentation examples
Produce address strings for screenshots and sample payloads without borrowing anybody else's real address.
Working across chains? The Ethereum Wallet API endpoint and the Solana Wallet API endpoint follow the same pattern with the same safety rule.
Privacy and limits
Generated keys travel over the network and must never hold real funds.
Nothing you send identifies you, because the request has no parameters at all. The free Bitcoin wallet API endpoint shares one ceiling with every other service here: 5000 requests per IP per 24 hours, with no API key and no account.
Generate keys as you need them rather than in bulk. A pair you never used is still a secret sitting in a log somewhere.