Public keys and origins
Understand why a public key can ship in frontend code and what limits where it works.
A pk_ez_... key is safe to ship in frontend code: it does not grant access to
your account. What limits a copied key is its own settings — the sites it works
on and the hosts it may fetch files from.
zip.download({
strategy: 'cloud',
publicKey: 'pk_ez_...',
files: urls,
});Is the public key a secret?
No. A pk_ez_... key is designed to ship in frontend code and remain visible
in browser developer tools. It only starts jobs within its settings; it does
not replace authorization on your own backend.
Do not expose a secret API key
Secret Cloud API keys belong on a trusted server. They are not accepted as a
safer substitute for publicKey in browser code.
What limits a copied key?
Each public key checks two independent boundaries:
| Setting | Contains | Protects |
|---|---|---|
| Works on (allowed origins) | Exact frontend origins such as https://app.example.com | Which browser applications may create sessions |
| Files from (allowed source hosts) | Asset hosts such as cdn.example.com | Which remote files Eazip Cloud may fetch |
A copied key used from another origin, or with a source outside its file hosts, is rejected.
How should environments be separated?
Add every intended origin to one public key when the environments share the same file hosts. Create separate public keys when staging and production need different hosts, limits, ownership, or key rotation.
Change these settings in the dashboard, not with extra SDK options — see Get a public key for the steps.