Free Solana Wallet API Endpoint

Why this endpoint is for test keys only

A Solana secret key is not a password on an account. It is the account. Nothing sits behind it: no recovery flow, no support desk, no second factor, and no way to freeze a transfer once it is signed. Anyone holding those 64 bytes can drain the address.

A secret cannot be un-known. This key was born in a process memory you do not control, then pushed through a TLS session that somebody else terminated. Deleting the response afterwards changes none of that. Treat every value the free Solana wallet API endpoint hands back as public from the moment it exists.

Now the useful half. Plenty of real work needs key material with the correct format and no value whatsoever.

Learning. One request shows how an ed25519 key pair, its base58 encoding and a Solana address relate to one another. Reading about that relationship is slower than watching three fields arrive together and taking them apart.

Testing wallet code. Parsing, storage, redaction and display logic all need input in genuine Solana format. Generate a pair, run it through your code, throw it away.

Throwaway addresses. Fixtures, screenshots and README samples all want an address string. Use a generated one instead of borrowing a stranger's real one.

For funds that matter, use a hardware wallet or well-audited local software. Generate the key offline, on a device you control, with a tool that 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/solana/generate_new_wallet

The response has exactly three fields. The values below are placeholders, written to show the shape and the length of each field. They are not a real key pair, and no real generated key is published on this page. The two strings have the right lengths, 88 and 44 characters, but they contain the letter O, which the base58 alphabet does not use, so nothing here can be mistaken for live key material.

{
  "private_key": "[1,2,3,4,5,6,7,8,1,2,3,4,5,6,7,8,1,2,3,4,5,6,7,8,1,2,3,4,5,6,7,8,1,2,3,4,5,6,7,8,1,2,3,4,5,6,7,8,1,2,3,4,5,6,7,8,1,2,3,4,5,6,7,8]",
  "private_key_base58": "PLACEHOLDERPLACEHOLDERPLACEHOLDERPLACEHOLDERPLACEHOLDERPLACEHOLDERPLACEHOLDERPLACEHOLDER",
  "public_address": "PLACEHOLDERPLACEHOLDERPLACEHOLDERPLACEHOLDER"
}

Generation is pure arithmetic and never touches the chain. The address you get back does not exist on Solana until something sends lamports to it.

Response fields

The double encoding of private_key is the first thing that trips people up. It arrives as a string, so a naive consumer ends up with the characters of an array rather than the bytes of a key. Run it through your JSON parser a second time, then hand the resulting integers to whatever expects a byte sequence.

A quick sanity check on any response: the base58 secret is 88 characters, the address is 44 characters, and both draw on the base58 alphabet alone. That shape does not vary. When a value in your test suite fails one of those checks, look at your own handling code first.

Every call returns a new pair. Nothing is stored, so a key you discard is gone, and a key you keep is your responsibility.

Why the free Solana wallet API endpoint returns two key formats

1. The byte array is what libraries expect

   Solana tooling thinks in raw bytes. A keypair file written by the standard command line tools is an array of 64 integers, and client libraries take the same 64 bytes when they build a keypair object from a secret. Writing code? This is the field you want, after the extra parse described above.

2. The base58 string is what wallet apps ask you to paste

   An import box in a wallet application will not accept 64 numbers separated by commas. It wants one unbroken line of base58, and that is exactly what private_key_base58 is: the same 64 bytes, nothing added and nothing withheld. Two encodings of one secret, not two secrets, so leaking either one leaks the account.

3. The address is the public key itself

   Solana does not hash the public key into a shorter address the way Bitcoin does. The 32 byte ed25519 public key, written in base58, is the address, which is why it is also the final 32 bytes of the secret key. Want to work that alphabet by hand? The Base58 Encode API endpoint encodes arbitrary input with the same character set.

One consequence of that design deserves attention before you build validation around it. A Solana address is plain base58 with no checksum, unlike the Bitcoin formats that wrap a checksum around the payload. A mistyped character usually produces another string that still decodes to 32 perfectly valid bytes, which is an address nobody holds the key to. Checking that a string is valid base58 and 32 bytes long is therefore a format check, not a proof that the address is one a human intended. Confirm addresses by copy and paste, never by eye.

Reading a balance is a separate endpoint

Generation and lookup are two different jobs, so they live on two different pages. To read the balance of any address in SOL and in lamports at the same time, see the Solana Balance API endpoint.

That call carries none of the risk described above. It is read-only and takes nothing but an address, which is public information by design. Point it at any address on the network, including one you generated here and including one you own.

Common uses

Several kinds of work suit the free Solana wallet API endpoint well.

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

Privacy and limits

Nothing you send identifies you, because the request carries no parameters at all. The free Solana 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.

Related APIs