An application is one product you sell, with its own end users, plans and payments. It runs in the region you pick when you create it, and that is where its data and its end users' data stay.
Create the application
On Applications, choose Create application: give it a name and pick its region from the ones currently offered; at the time of writing there is one. No region is preselected, and the button stays disabled until both are filled in.
The region cannot be changed later
All of the application's data, and its end users' data, stays in the region you pick. To move to another region, create a new application there.
How many applications an organization can hold depends on its plan. When you reach the limit, the dialog says so and links to Pricing. Applications cannot be added one at a time; a larger plan includes more.
Provisioning takes a moment. The application's page refreshes on its own and shows the status: provisioning, active, or failed. A failed application is rolled back and does not count toward your limit.
Save the SDK key and the API address
When the application is created, a panel titled "Your secret key" shows two values, each with a copy button; close it with I have saved the key only once you have stored the key:
| Value | What it is | Shown again? |
|---|---|---|
| Secret key | The application's SDK key (sr_live_...): the one credential your backend needs | No. It is shown only in this panel; once you confirm that you have saved it, it is gone |
| API address | The base address of your application's region, which your backend talks to | Yes, on the application's page under Connection, at any time |
Store the secret key as a server-side secret before you confirm the panel. Never put it in a browser bundle or a repository.
If you lose the key, the developer console cannot show it again. Create a new SDK key in the application's operator console, under Settings, Project Credentials, and revoke the old one once your service runs on the new key; the order is in Backend.
If the panel or the application's page shows "API address unavailable", the region's address could not be loaded. Reload the page later, and contact us if it persists.
The application's page
Opening an application on Applications shows:
- Connection: the application ID, its region and its API address, each with a copy button. A note reminds you that the secret key was shown once.
- The install command for the Server SDK and three environment lines (
SHIPREV_BASE_URL,SHIPREV_API_KEY,SHIPREV_APP_ID), ready to copy. Backend walks through them. - Open operator console, available once the application is active.
Open the operator console
Each application has its own operator console in its region. That is where you define what you sell (products, capabilities and plans), see your customers, connect the Stripe account you are paid into, and set how your end users sign in. The developer console only takes you there.
Choose Open operator console on the application's page. You arrive signed in with the account you used in the developer console; there is no separate password.
The application's page also links straight to four places in its operator console: Products and plans, Customers, Payment settings and Customer sign-in. The next pages use all four.
If the link between your region and ShipRev is interrupted
Two links are involved: the one between your backend and your application's region, and the one between the region and ShipRev. This section is about the second. Your application's region keeps working on its own if its connection to ShipRev is interrupted:
- Your end users carry on. Sign-in, entitlement rulings, reads and usage reporting are served by the region as usual.
- After the validity period, new writes are restricted. The region relies on ShipRev's last answer about your plan for a limited period, 72 hours by default. Once that period has passed without a new answer, new subscriptions, plan changes and other new writes in your operator console and public API are refused with
403 UPSTREAM_LEVEL_RESTRICTED; reads, sign-in and usage reporting keep working. - Usage recorded during the interruption is kept. Every usage event the region accepts is also written, in the same database transaction, to a queue of events owed to ShipRev; the queue is delivered once the link is back, and a replayed event is counted once. The restriction lifts on ShipRev's next answer.
The first link, between your backend and the region, is the Server SDK's job, and there the answer depends on you: usage that your backend has buffered but not yet delivered survives an outage only in the journal and host_adapter backlog modes, not in the default memory mode if your process restarts meanwhile. See the backlog modes.