A key that belongs in view source
parse_public_ keys are browser-safe by design. Full plan capability, locked to your domains, and the prefix says so out loud.
Everyone ships an API key to the browser eventually. Most keys are not built for it.
parse_public_xxxxxxxxxxxxxxxxxxxx
A public key carries your full plan, every endpoint, same quotas. The fence is not a crippled feature list, it is the domain lock: each public key has its own list of allowed domains, and the API checks the request's origin against it. example.com covers itself and every subdomain. localhost always works without being listed, so local dev never needs a second key. A request with no origin at all is rejected, so the key is useless in a server script someone scraped it into.
The prefix is the feature
parse_public_ is deliberately loud. Anyone reading your page source, or reviewing your pull request, can see at a glance that this key is supposed to be there. A secret key in the browser looks exactly like a mistake because it is one. Validate emails and phone numbers in the signup form, client side, on your plan, without a proxy endpoint whose only job is hiding a key.
Try it
Mint one on the keys page, set the domain, and call /email from your own frontend. View source all you want.