OrderCloud Environments

Suggest an edit
Robert Watt

Updated by Robert Watt

July 10th, 2021

The Portal allows users to access marketplaces from OrderCloud Sandbox, Staging, and Production in a single user interface. These environments have been available for some time; however, OrderCloud customers haven't yet been able to utilize them in a meaningful way. Each environment has a unique purpose, which is detailed below.

What is an Environment?

An environment is an isolated, independent instance of the OrderCloud API provisioned with its own host name, dedicated compute resources, isolated data storage, etc. Up until this release, any marketplace created in the Portal was created in "Production". Developers that required a separate marketplace for testing purposes had to create a "copy" of their production marketplace, and manually keep it in sync. Furthermore, developers that wanted to test changes to the OrderCloud API against their applications couldn't do so until the API release was completed - which is not ideal.

Providing access to additional "environments" means that you can test experimental app code, and even unreleased API features, without consuming resources dedicated to your production application(s). Each environment has its own API URL, purpose, and behavior outlined below.

What Environments does OrderCloud offer?

With the release of Portal version 1.0.74, this question becomes a bit more complex. Each region offers the three environments listed below; however, the base API url will be different for each region. Currently, "Azure Us West" is the only supported region and the API urls you see below correlate to that region. As new regions are released, you can check your marketplace OrderCloud API Instance information to figure out the correct base API url to use.



Previously our only public-facing environment, Production will now be now reserved for live apps with real buyers and sellers performing real transactions, and nothing else. It's provisioned for high performance, high availability, and geo-redundant data protection. In order to keep this premium environment performing at the highest possible level, we'll be doing a bit more "gatekeeping" of what goes in, and assisting with transitioning the many "test" and "dev" marketplaces that currently live there; we have better homes for them now.



If you have live apps deployed to production and want a place to test code changes, or if you want to test unreleased API features against existing app code, Staging is the place to do it. Each Sunday morning we restore a copy of all of your production data (marketplaces, users, products, orders, etc.) to Staging, meaning you always have near-current, near-"real" data to test against. (We do wipe a few things like webhook URLs that could trigger external events. You probably don't want an email sent to a real customer when you pretend-ship their order!) The caveat here is that any data created or changed in Staging will only survive until the end of the week; it will be overwritten by a fresh snapshot of production data for the following week.



If you're building a new app that does not have a production equivalent, or you have a need to test against long-lived "fake" data that is never overwritten, Sandbox is the right choice. Although this might seem like the most seamless transition for those "test" and "dev" marketplaces currently in production, we would strongly encourage you to consider transitioning to Staging first. If you can live with the caveat of weekly data overwrites, then eliminating the need to do your own data synchronization should be a no-brainer.

What are the


You can expect this blog post to improve over time - with more detail on exactly how to take advantage of these new environments in the Portal coming soon. If you have any questions or concerns, please don't hesitate to reach out in the OrderCloud Slack Community.