Public keys and origins
Understand why a browser key can be public and how Public App policy limits where it is used.
A direct Cloud call identifies its Public App with a publicKey:
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 identifies a Public App; 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?
The Public App policy checks two independent boundaries:
| Policy | Contains | Protects |
|---|---|---|
| Allowed application origins | Exact frontend origins such as https://app.example.com | Which browser applications may create sessions |
| 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 the host policy, is rejected.
How should environments be separated?
Add every intended origin to one Public App when the environments share the same source policy. Create separate Public Apps when staging and production need different hosts, limits, ownership, or key rotation.
Policy changes belong in the dashboard, not additional SDK options. Follow Get a public key for the current dashboard steps.