Free Ethereum Wallet API Endpoint

Why the free Ethereum wallet API endpoint is for test keys only

Never send real funds to an address generated here. The private key is created on a remote server and travels back to you across the internet. A key that has left the machine it was born on is no longer secret, whatever the transport encryption protected it with.

This is not a warning about a hypothetical attacker. A private key made somewhere other than your own machine has already 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 Ethereum wallet API endpoint hands back as public knowledge from the moment it exists, and assume anything sent to that address can be taken.

Now the useful half. Plenty of everyday work needs key material in genuine Ethereum format with no value attached, and that is precisely what this generator supplies.

Learning. One request shows how a private key and the address derived from it relate to each other. Reading about that relationship takes longer than watching two fields arrive together and pulling them apart.

Testing wallet code. Parsing, validation, checksum handling and storage all want input in real address format. Generate a pair, run it through your code, throw it away.

Throwaway addresses. Fixtures, screenshots, README samples and API examples all need an address string. Use a generated one instead of borrowing somebody else's real address from a block explorer.

For an address that will hold value, generate the key where it never touches a network service. Use a hardware wallet, or audited local software running offline. Then verify the address on the device screen rather than trusting whatever a piece of software prints.

Generate a key pair

No headers, no body, no authentication. The base URL is https://aisenseapi.com/services/v1 for every service in the free public REST APIs catalogue.

curl https://aisenseapi.com/services/v1/ethereum/generate_new_wallet

The response carries exactly two fields. Both values below are placeholders, written only 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",
  "public_address": "0xabcdef0123456789abcdef0123456789abcdef01"
}

Every call returns a different pair. There is no seed phrase, no derivation path and no way to recover a pair once you drop the response.

Response fields

Field	Type	Description
private_key	string	The 32-byte secp256k1 private key as 64 hexadecimal characters, with no 0x prefix. This is the entire secret.
public_address	string	The address derived from that key: 0x followed by 40 hexadecimal characters. The letters come back mixed case, but the casing is not a valid EIP-55 checksum.

Nothing is stored on our side. A key you discard is gone, and a key you keep is your responsibility.

How the two values relate

The private key is the whole secret
32 random bytes, printed as 64 hex characters. The address is derived from the key, never the other way round. Whoever holds the key controls whatever the address holds, which is exactly why a key that arrived over a network belongs in a lesson and not in a wallet.
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, print in a QR code or paste into a README, while the key never is.
The mixed case is not an EIP-55 checksum
Letters inside public_address arrive in mixed case, yet that casing does not encode a valid EIP-55 checksum. Libraries that validate it, including getAddress in ethers.js, reject the value outright. Lowercase the address first, then let the library apply its own checksum.

Reading a balance is a separate endpoint

Generation and lookup are two different jobs, so they live on two different pages. To read the ether held by any address, in both wei and ether, see the Ethereum 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. Point it at any address you like, including one you generated here and including one you own.

Common uses

Several kinds of work suit the free Ethereum 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 logic against real Ethereum format and zero value.

Teaching key material

Show a class, in one request, how a private key and an address are two views of the same thing.

Documentation examples

Produce address strings for screenshots and sample payloads without borrowing anybody else's real address.

Working across chains? The Bitcoin Wallet API endpoint and the Solana Wallet API endpoint follow the same pattern under the same safety rule.

Privacy and limits

The key pair is created on our server and returned in the response body. What that server does or does not keep is not something you can verify from outside, which is precisely why the pair is only ever safe for testing.

Nothing in the request identifies you, because the request carries no parameters at all. The free Ethereum 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 somebody's log.