Sandbox and production

Recurly gives you a practice copy alongside the real one. Connect the practice copy first, and make sure you can always tell them apart.

Recurly gives you two separate worlds:

Production is real. Real customers, real subscriptions, real money moving.

Sandbox is a practice copy. Same system, same screens, test data, no real cards and no real charges. Nothing you do there reaches a customer.

They are entirely separate — separate data, separate API keys — and Retrixus treats them as separate instances with separate aliases.

Start with sandbox

If you have a sandbox site, connect that one first. Ask it questions, see what the answers look like, let a colleague try it. It costs nothing to get wrong.

When you connect a production site later, it is the same six fields and the same two minutes.

Tell Retrixus which is which

When you add an instance you choose its environment: sandbox or production. Retrixus shows that label everywhere the instance appears, so an answer from the practice copy is never mistaken for an answer about a real customer.

Like the alias, the environment is fixed once the instance is created. A site does not migrate from practice to real — a production site is a different site, added separately.

How to tell which Recurly site you are looking at

The API key you paste decides which site Retrixus talks to — the environment label is Retrixus's record of what you told it, not a check on the key. So the key has to come from the right place.

If you are unsure, the safest move is to create the key while looking at the site you intend to connect, and paste it straight into Retrixus — see step 1 of the quickstart.

The one that matters most

Retrixus checks the key against the subdomain you gave it and refuses if they do not match, so a key from the wrong company is caught immediately.

What it cannot catch is a key from the right company's other environment, if the subdomain matches. That is why the environment label, the alias, and a moment's care in step 1 are all worth having: three small habits, each of which independently keeps a practice question from being answered with real data, or the reverse.

Related

• Instances and aliases — why the alias and environment cannot be changed
• Read-only and read-write — the other setting worth being deliberate about on a production site