Skip to main content
API keys are how your applications authenticate with Ecrypt. Every request your code makes to the Ecrypt API — whether it’s running a charge, looking up a customer, or pulling a report — has to include an API key that identifies the merchant account and the level of access being requested. Ecrypt issues three types of keys, each scoped to a different use case:
  1. Private Key — server-side, full-access. Use it from your backend to create transactions, manage customers, and perform any action a logged-in dashboard user could.
  2. Public Key — client-side, tokenization-only. Safe to embed in browser or mobile code so you can tokenize cards without ever touching cardholder data on your own servers.
  3. Reporting Key — read-only, analytics-only. Use it from reporting or BI tooling to pull transaction history and reports without granting any ability to move money or change data.
This guide covers the API/Security Keys page where you generate, view, and revoke keys for each merchant account.
From the left sidebar: Settings → Developer Tools → API/Security Keys The page is split into two sections stacked vertically:
  1. Create New API Key — the form at the top for generating a new key.
  2. Key’s Table — the list of every key currently provisioned for this merchant account.

​
Key Types

TypeWhat it can doWhere to use it
Private KeyFull read/write access — create and manage transactions, customers, subscriptions, vault entries, settings, etc.Server-side code only. Never expose in client-side code, mobile apps, or public repositories.
Public KeyTokenize card and bank information on the client side. Cannot list, modify, or charge stored data on its own.Browser JavaScript, mobile apps, hosted checkout forms — anywhere the user’s device handles raw card data and you want to avoid sending it through your own servers.
Reporting KeyRead-only access to transactions and batches. Cannot create, modify, void, refund, or otherwise change state.BI tools, finance dashboards, reconciliation scripts, third-party reporting integrations.
Generated keys are formatted with a type prefix so you (and your code) can tell them apart at a glance:
  • pri_<merchant>_<unique> — Private Key
  • pub_<merchant>_<unique> — Public Key
  • rpt_<merchant>_<unique> — Reporting Key
(Older keys may appear as a plain hex string with no prefix — these are legacy keys and continue to work; the Type column still labels them correctly.)

​
Create New API Key

The form at the top of the page generates a new key.
FieldRequiredNotes
Description of API keyYesFree-text label so you can identify the key later (e.g., “Production server”, “Marketing dashboard”, “Mobile app v3”). Tooltip on the info icon: “Please enter your API key description. (max. 47 characters)“
Key TypeYesRadio buttons: Private Key, Reporting Key, Public Key.
Click GENERATE NEW KEY to create it. The new key appears in the Key’s Table below.

​
Key’s Table

The list of every key issued for this merchant account.
ColumnNotes
TypeColor-coded badge: PUBLIC (green), REPORTING (blue), PRIVATE (white/grey).
DescriptionThe label you entered when generating the key.
KeyThe full key string. A copy icon next to the value copies the key to your clipboard.
ActionDelete.
The key value is displayed in full once it’s generated and visible on subsequent visits — copy it whenever you need it. Pagination controls (rows per page, page arrows) appear at the bottom right.

​
Copy a Key

Click the small clipboard icon to the right of the key string to copy it. You can then paste it directly into your code or your secrets manager.

​
Delete a Key

Click the red Delete action to revoke a key. A confirmation dialog appears:
Are you sure you want to delete this key?
Buttons: DELETE / CANCEL. Deletion is immediate. Any request made with the deleted key will be rejected the moment you confirm.

​
Tips & Best Practices

Treat Private Keys like passwords. Anyone with a private key can charge cards, refund money, change customer data, and modify settings on the merchant account it belongs to. Never paste a private key into client-side code, browser JavaScript, mobile app bundles, support tickets, or public repositories. Store private keys in your environment variables, secrets manager (AWS Secrets Manager, Doppler, 1Password, etc.), or another encrypted store — and only inject them at runtime. Use Public Keys for everything client-side. The whole point of a public key is that it can be embedded in browser or mobile code without putting cardholder data at risk. Public keys can only tokenize input — they can’t pull customer lists, run charges, or read transaction history. If your integration is sending card data through your own servers when it could be tokenizing client-side, switch to a public key flow to reduce your PCI scope. Use Reporting Keys for read-only systems. BI dashboards, reconciliation scripts, and finance team tools usually only need to read transactions and don’t need to make state changes. Giving those tools a Reporting Key (instead of a Private Key) means a leak from your BI tool doesn’t translate into the attacker being able to charge cards. The same principle applies to any contractor or third-party vendor who only needs read access. Give every key a clear Description so you can identify it later. “Production server” and “Staging server” are far more useful six months from now than two anonymous keys that look identical. If you generate a separate key per integration (recommended), include the integration name in the description (e.g., “Shopify webhook”, “Zapier”, “QuickBooks sync”). Rotate keys whenever someone with access leaves the team, when you suspect a key may have been exposed, or as part of a regular security review. Rotation is just a sequence: generate a new key, deploy it to wherever the old one was used, confirm everything is working with the new key, then delete the old one. Because old and new keys can coexist, you can do this without downtime. If a key is ever exposed — committed to GitHub, posted in a chat, sent to the wrong recipient — delete it immediately. Don’t wait. A revoked key can’t be misused, and a new key is one click away. Finally, remember that API keys are scoped to a single merchant account. If you operate multiple merchants, each merchant has its own keys, and a key generated for Merchant A cannot interact with Merchant B’s data. Switch merchants in the top-left “Your Merchant Accounts” picker before generating or managing keys for a different account.