Two kinds of access reach your application from your side: people on your team, who work in the developer console and the operator console, and your backend, which holds an SDK key. Neither is an end-user account. Your team and your end users are separate pools of accounts, and neither accepts the other's credentials.
Your team
In ShipRev Cloud, your team is the organization you created in the developer console. Owners and admins invite people by email under Settings, Members, and choose their role there; invited people create their account from the invitation email. Invite your team walks through it.
| Role | In the developer console |
|---|---|
| Owner | Change the organization, its plan and its applications, and manage other owners |
| Admin | Change the organization, its plan and its applications; cannot make anyone an owner, or change or remove an owner |
| Member | See the organization, its plan and its applications |
| Viewer | See the organization, its plan and its applications |
An organization always keeps at least one owner. In an application's operator console the roles mean the same: any role can read, changes need an owner or admin, and a few actions, such as rotating a gate's signing key, need an owner. The operator console says on each settings page when a change needs an owner or admin, and the Management API reference gives the rule for its endpoints.
To close your organization or leave one you were invited to, see Close your organization.
The key your backend holds
Your backend needs one credential: the application's SDK key. It starts with sr_live_, belongs to exactly one application, and lets the Server SDK verify session tokens, rule on entitlements, reserve and report usage for that application. It does not open the operator console or the management API.
| Property | Value |
|---|---|
| Scope | One application; a key cannot be widened to others |
| Shown | Once, when it is created. ShipRev keeps only a hash of it |
| Expiry | The key created with the application never expires. Keys you create later can expire after 7, 30 or 90 days or one year, or never |
| Stored in | A server-side secret, for example SHIPREV_API_KEY. Never in a browser bundle or a repository |
There is one kind of SDK key; there is no separate test key. Test and live payments are told apart by the payment connection, not by the key.
The SDK exchanges the key for a short-lived service token, valid for up to one hour, and renews it on its own. That is the only use of the key: if it leaks, whoever holds it can read your application's entitlements and report usage for it, so treat it like a database password.
Create, rotate and revoke keys
SDK keys are managed in the application's operator console, under Settings, Project, Credentials. Only owners and admins can create or revoke them.
- Create a key when you add a service, or to rotate. It is shown once; store it before you close the panel.
- Rotate by creating a new key, deploying your service with it, checking that the client reaches
LIVE, and only then revoking the old one. Rotate the SDK key, or replace a lost one gives the order and the reason for it. - Revoke a key that is no longer used or may have leaked. From that moment the region refuses to exchange it, so a process using it cannot start, reconnect or renew. A service token it already obtained stays valid until it expires, at most one hour later. Revocation cannot be undone.
Give each service its own key when you run several. You can then rotate or revoke one without touching the others, and the list shows each key's name, prefix, status and expiry so you can tell them apart.