2. Test accounts and sandbox API keys

Description

By the end of this lesson you will be able to obtain and use a test account and a sandbox API key from an external provider —the CRM, a payment gateway, an email API— so your workflow talks to a real service in its test mode, without touching production data or production money. You will be able to tell a test key from a production key at a glance, you will hook up each type of key with the per-environment credentials you set up in Module 4, and you will have a clear rule —a short, hard list— of which things never get tested directly against production, no matter what.

This matters because it is the first point of the pre-production checklist, and the one that makes all the others possible. If your test hits the real CRM, no amount of synthetic data or assertions can save you: production is already polluted. The sandbox key is what turns your dev instance from "a place where I run things" into "a place where I run things with no real consequences." It is the border between the sandbox and the world.

Connection to the module: in lesson 1 you saw that testing against production has three costs —data, money, reputation. This lesson attacks the first and third at the root: with a sandbox key, the order-triage HTTP Request node writes to a test CRM, not the real one, so polluting data and pushing effects out into the world stop being possible by design. It leans entirely on Module 4: there you learned to have a separate credential per environment; here we give that credential its content —test key in dev/staging, real key only in prod. Lesson 3 puts the inputs (synthetic data) into the workflow that this lesson has already connected to a safe destination.

The model home and Monopoly money

Picture a builder who wants to sell apartments in a building that is not finished yet. They do not take customers to the real apartment —it is a construction site, it is dangerous, and every visit makes it dirtier. They build a model home: an identical replica, with the same finishes, the same furniture, the same layout, but that is not where anyone is actually going to live. The customer walks through it, tries the faucets, turns on the lights, gets a complete sense of what their apartment will be like. Everything feels real. And yet, if they trip and break a vase in the model home, it is a prop vase that gets replaced; nobody's actual home was damaged.

A test account is a service's model home. The provider —say, the CRM Cumbre uses— gives you a separate account that works exactly like the real one: same API, same responses, same behavior. But its data is props. The "customers" living there are made up. If your workflow creates, modifies, or deletes records in the test account, it touches props, not Cumbre's actual operation. You walk through the whole system, with total realism, without being able to break anything that matters.

And the sandbox key —also called test key, or sandbox API key; they are synonyms— is the key that opens the model home instead of the real one. An API key is a credential: a long secret string that your workflow sends to the provider to identify itself, like a password that says "I am Cumbre, let me in." Serious providers give you two different keys for the same account:

• The production key (live key) opens the real house. The actions you take with it are real: the charge gets charged, the email gets sent, the record lands in the CRM the whole team sees.
• The test key (sandbox key) opens the model home. The actions look and respond the same, but they do not produce real effects: the "charge" is fake, the "email" reaches nobody, the record lands in a test CRM you can empty out whenever you want.

The same call from your workflow, the same API, the same code. The only thing that changes is which of the two keys you use. And that single difference decides whether you are playing in the sandbox or in production.

There is an even simpler picture for the test key: it is Monopoly money. When the AI Agent node calls a language model, or the HTTP node hits a payment gateway in test mode, the transactions get processed end to end —the gateway responds "charge approved," returns an identifier, the whole flow works— but with toy bills. Nobody loses or gains a single real peso. You can "charge" a thousand times to test, and at the end of the month the invoice is zero.

Worked example: a payment gateway's test mode

To see the concrete pattern, let's take the market's most standardized case: the test mode of a payment gateway like Stripe. order-triage does not charge anything today, but this example is the cleanest way to understand the mechanism, and you will recognize it in any serious provider.

A payment gateway in test mode typically gives you:

A pair of marked keys. A test key and a production key, and the crux of the matter: they are marked right in the text itself so you can tell them apart at a glance. In Stripe, for example, secret test keys start with sk_test_ and production ones with sk_live_. The word test or live is embedded right into the credential. That is not an accident: the provider knows confusing them is the most expensive mistake you can make, so it makes the distinction visible.

sk_test_51H8xY2eZvKY...    ← test key: the "test" warns you. Sandbox.
sk_live_51H8xY2eZvKY...    ← production key: the "live" warns you. Real money.

Test cards that do not exist. To test a charge without a real card, the gateway publishes test card numbers. Stripe's best-known one is 4242 4242 4242 4242: in test mode, that number simulates a successful charge; in production mode, it is an invalid card that charges nothing. There are other numbers to simulate hard cases —declined card, insufficient funds, network error— exactly the edge cases lesson 3 is going to teach you to include.

A separate dashboard. Test charges show up in a test view of the dashboard, kept apart from real charges, so you never confuse them when reviewing.

What to expect when using it. You configure the HTTP Request node (or the gateway's dedicated node, if one exists) with the sk_test_... key, send it the 4242... card, and run the workflow. The gateway responds exactly the way it would in production: a 200 OK, a charge identifier, a "succeeded" status. Your workflow's entire downstream flow runs with realistic data. And yet not a single peso moved, no real card was involved, and you can repeat it as many times as you want. That is a zero-cost test against a real service.

A hygiene note, because details go stale: the exact prefix (sk_test_), the card number (4242...), and the mode's name (test mode) are Stripe's and accurate as of when this guide was written (2026). Another provider calls them something else, and even Stripe could change them. The idea is universal —two marked keys, test data, a separate dashboard— the exact names, always verify against the docs of whichever provider you use. This is the same "verify against your own version" habit you carry over from earlier modules.

Cumbre's CRM: sandbox account and test key

Let's bring the pattern down to order-triage. The piece that matters here is the HTTP Request node that writes to the CRM: it is the side effect we do not want to fire against production while testing.

Cumbre's CRM provider —like almost any serious CRM— offers some form of test environment. In practice you will run into one of these three setups, and it is worth knowing them because they change how you configure the credential:

Setup A: a separate sandbox account. The provider gives you a second account, apart from the production one, meant for development. It has its own base URL (for example https://sandbox-api.crm.example.com instead of https://api.crm.example.com) and its own keys. This is the cleanest separation: the test account and the real one do not even see each other. This is what the big CRMs offer, sometimes under the name "developer account" or "sandbox environment."

Setup B: a test key inside the same account. The provider does not separate the accounts, but gives you a key marked as a test key (just like the gateway's sk_test_) that, within the same account, operates on a test data space. Less clean than A, but good enough.

Setup C: no native test mode. Some providers —especially smaller ones or a company's internal APIs— simply do not offer a sandbox. Here there is no magic key waiting for you: you have to build your own separation, and that is exactly lesson 4 (guarding the side effect so it does not fire) combined with a test account you set up by hand inside the same system. This is the most inconvenient case and the most common one in the real world, so do not be surprised if it is the one you get.

For the thread of this guide, let's assume Cumbre's CRM is in setup A: there is a sandbox account with its own base URL and its own test key. What follows is how you wire up that key so it never crosses with the production one, and that is where Module 4 does all the heavy lifting.

Hooking the key into per-environment credentials

Here is the heart of the lesson, and where it connects with what you already built. In Module 4 you learned that every environment has its own credential, and that the workflow does not store the key itself but a reference to a credential that gets resolved on each instance. Let's recall the idea quickly, because it is what makes this work.

order-triage does not carry the CRM key hardcoded into the HTTP node. It carries a reference to a credential named, say, CRM API. Each of your three n8n instances has a credential with that same name, but with different content:

Instance	CRM API credential contains	Base URL	Effect of a call
dev	The CRM's sandbox key	https://sandbox-api.crm.example.com	Writes to the test CRM. Reversible.
staging	The CRM's sandbox key	https://sandbox-api.crm.example.com	Writes to the test CRM. Reversible.
prod	The CRM's production key	https://api.crm.example.com	Writes to the real CRM. Final.

Notice how elegant the arrangement is: the workflow is identical across all three environments. The same order-triage JSON, byte for byte, runs in dev, in staging, and in prod. There is no "test workflow" and a "production workflow" —that would mean having two versions that drift apart, exactly the problem Module 1 taught you to hate. There is one workflow that references a CRM API credential, and it is the environment that decides whether that credential points at the sandbox or at the world. You change environment, you change destination, without touching a single line of the workflow.

This has a consequence worth underlining: testing in a sandbox is not modifying the workflow, it is running it in the right environment. The beginner's mistake is to make a copy of the workflow, hand-edit its key to point at test, and test against that copy. It works once, and then it rots: the copy and the original drift apart, you test against one and promote the other, and the day they differ you did not actually test what you promoted. Module 4's arrangement avoids that entirely: you test the same artifact you are going to promote, just in an environment where its effects are props.

What it looks like in the credential

Concretely, on your dev instance, the HTTP node's CRM API credential looks roughly like this (the exact field names depend on the credential type you use —a "Header Auth" credential, an "API Key" one, a generic one— verify them in your own panel):

Credential name:   CRM API
Base URL:          https://sandbox-api.crm.example.com
Header:            Authorization: Bearer crm_test_a1b2c3d4...
                                          ^^^^ the "test" mark warns you

And in prod, the credential with the same name contains:

Credential name:   CRM API
Base URL:          https://api.crm.example.com
Header:            Authorization: Bearer crm_live_z9y8x7w6...
                                          ^^^^ the "live" mark: real money

What to expect: when you run order-triage in dev, the HTTP node pulls the CRM API credential from that instance —the one holding the crm_test_ key— and hits the sandbox. In the node's output you see a real response from the test CRM: a 201 Created, a record identifier. You go to the sandbox CRM's dashboard and there is your test record. You go to the production CRM and there is nothing new. That is the signal that the separation works: the action happened, it was real and verifiable, and it landed on the safe side.

The credential smoke test: verify the destination before you trust it

Before running a real test, there is a thirty-second check worth turning into a reflex, especially the first time you set up a new credential: confirm where it points, with an action that pollutes nothing. A key marked test should go to the sandbox, but a distracted click could have copied the wrong base URL, or the key and the URL could have gotten crossed. Do not take it for granted: verify it.

The safe way is to run a read-only action first —list records, look up a customer— and see what comes back. If the sandbox CRM has three prop customers with names like "Test Café" and your read returns those three, you are pointed at the sandbox. If it returns the real names of Cumbre's coffee shops, stop: you are pointed at production, and a test key that returns real data means something is misconfigured. Same idea with a reversible action: create a test record, verify it shows up on the sandbox dashboard and not on the production one, and delete it.

It is the same spirit as the worked example, now turned into a habit: never run a side effect against a credential whose house —model or real— you have not confirmed. Thirty seconds of reading saves you lesson 2's worst mistake.

An honest note about sandboxes: the model home is not the home

It is worth saying something almost no guide admits: a sandbox is a model home, and a model home is not identical to the home you are actually going to live in. It resembles it a great deal, enough to test almost everything, but it has differences worth keeping in mind, so none of them catches you by surprise on promotion day.

The sandbox sometimes behaves differently than production. Some providers run their test environment on a slightly older version of the API, or with certain features disabled, or with different usage limits. A test charge always "approves" with the 4242... card, but in production a real card can be declined for a thousand reasons the sandbox does not simulate. A sandbox CRM might accept a record that production would reject because of a validation that only exists in the real one.

The sandbox usually has less data and less load. In test you have three prop customers; in production, hundreds. A workflow that works fine with three records can run into pagination in production, into longer response times, or into a customer whose name has a character that breaks your parsing. The sandbox does not show you the real scale.

This is not an argument for testing against production —that would be throwing the baby out with the bathwater. It is the argument for the second rung you already built in Module 4: staging. The reason staging exists is exactly this gap. dev is the model home far from the construction site, where you iterate fast and break things without fear. staging is the model home built right next to the real one, with the same materials and as close to production as possible —the largest data volumes you can manage, the closest configuration— to catch exactly the differences a toy sandbox hides. That is why in the table above staging also uses the sandbox key, but it is thought of as "the dress rehearsal," not as "the rough draft."

The practical rule that comes out of this: you iterate in dev, you rehearse in staging, and you still keep a close eye on the first run in prod. The sandbox reduces risk enormously; it does not take it to zero. Knowing that saves you from the false confidence of "it passed in the sandbox, so it cannot possibly fail in production" —which is a more sophisticated version of lesson 1's "it ran once and it worked."

What NEVER gets tested directly against production

There is a short list of actions that never get tested against production, ever —not "just once to see," not "carefully," not "it is a small change." This is not a style recommendation; it is a hard rule, because these actions share one property: they have no undo. Once they happen in production, they happened.

1. Charging money. A charge to a real card is real. Even if you refund it, the transaction stayed on record, maybe a fee, maybe a notification to the customer. Charges are always tested with the gateway's test key and test cards. Never with a real card, not even your own.

2. Sending messages to real people. An email, an SMS, a WhatsApp message, a Slack message to a real channel: once sent, it reached someone. There is no recall. Sends get tested against a test email account, a number of your own, or a sandbox channel —never against the company's customer list. This is the one that damages reputation fastest: a test email with placeholder text that reaches Cumbre's 400 coffee shops is an incident people talk about for months.

3. Writing to or deleting from the production database. Creating, modifying, or deleting real records —customers, orders, inventory— contaminates or destroys data the operation depends on. A misaimed DELETE does not undo itself. Test it against the sandbox account or a test database.

4. Firing irreversible actions on third-party systems. Publishing a post, issuing a tax invoice, generating a purchase order to a supplier, moving money between accounts. Anything that, once done, leaves your control.

The rule for recognizing them is a single question: "if this runs by mistake, can I undo it without anyone noticing?" If the answer is no —because it reached someone, moved money, or deleted something— then it is an action that does not get tested against production, period. When the provider gives you a test mode, you use it. When it does not (setup C above), it is your job to build the protection yourself, and that is exactly what lesson 4 solves: guarding the side effect so that, in test mode, it does not even get attempted.

Notice that the first three are exactly lesson 1's three costs: money (charging), reputation (sending messages), data (writing/deleting). The list is not new; it is the same threat, now seen as an operational rule of "what not to do."

Common mistakes

Confusing the test key with the production key (practical and expensive). What happens: someone copies the wrong key into the credential —puts the live one where the test one was supposed to go— and their "test" in dev ends up charging for real or writing to the real CRM. Why it happens: the two keys look alike; they are long, ugly strings, and at a quick glance crm_test_a1b2 and crm_live_z9y8 look equally unreadable. How to spot it: before running a test, read the key's mark —test/live, sandbox/prod— and confirm the base URL. If your test leaves a record that shows up in the production CRM, you used the wrong key. How to fix it: take advantage of the fact that keys come marked; make it a habit to check the mark the way a pilot checks an instrument before takeoff. And structure your credentials by environment (Module 4) so the live key lives only on the prod instance, physically separated, so it is not even available to be copied by mistake into dev.

Putting the key inside the workflow instead of in a credential (practical). What happens: someone pastes the CRM key directly into a field of the HTTP node —into the URL, into a hand-typed header— instead of using an n8n credential. Now the key travels inside the workflow's JSON. Why it happens: it is the obvious shortcut; you write the key right where you need it. How to spot it: if, when exporting order-triage with the CLI (Module 3), you see the key in plain text inside the JSON, you put it in the wrong place. How to fix it: the key always goes in a credential, and the workflow only references it —this is exactly what you learned to separate in Module 3, lesson 3, and to manage per environment in Module 4. A key inside the workflow breaks the per-environment separation (the JSON would carry a fixed key instead of resolving it per instance) and, worse, it gets uploaded to Git in plain text.

Assuming every provider has a sandbox (conceptual). What happens: someone plans their test assuming the CRM, the API, or the service will give them a test key, and discovers halfway through that no such thing exists (setup C). Why it happens: big, well-known providers almost always have a sandbox, and it is easy to generalize. How to spot it: before designing the test, search the provider's docs for the words "sandbox," "test mode," "test key," "developer account." If they do not show up, there is no native test mode. How to fix it: do not get stuck. When there is no sandbox, you build the protection yourself —a test account you set up by hand inside the same system, plus the gate from lesson 4 that cuts off the effect before it happens. Knowing in advance which setup you are in (A, B, or C) is part of planning the test.

Exercises

Exercise 1 — Tell the keys apart. For each of these five credentials, say whether it is a test one or a production one, and what tipped you off: (a) sk_test_51H8xY2...; (b) Authorization: Bearer crm_live_z9y8x7; (c) base URL https://sandbox-api.crm.example.com; (d) pk_live_4eC39Hq...; (e) a key a1b2c3d4e5f6 with no mark and no URL.

See solution

(a) Test — the _test_ right in the key's text. (b) Production — the _live_ in the key. (c) Test — the word sandbox in the base URL; even without seeing the key, the destination is the sandbox. (d) Production — the _live_; the pk_ prefix indicates it is a public (publishable) key, but that is a different dimension: public/secret is separate from test/production. (e) Cannot be known — it has no mark and no URL. And that is the point of the exercise: an unmarked key is dangerous precisely because you cannot tell it apart at a glance. If you run into one like this, the only way to know is to test a reversible action and see where it lands, or ask the provider.

Why it works: the habit this trains is reading the mark before running, not after. The two dimensions —test/production and public/secret— are independent, and confusing them is a common mistake; that is why I included (d).

Exercise 2 — Design the credentials table. order-triage is going to add a node that emails the customer when their order is put into manual review, using an email API (for example, a service like SendGrid or similar). Write the table of what the Email API credential should contain in each of the three environments —dev, staging, prod— with which key and what effect a call would have.

See solution

Instance	Email API credential	Effect of a call
dev	The email service's test key (or "sandbox mode" enabled)	The email gets processed but is not delivered to anyone / it goes to a test capture inbox. Reversible.
staging	Test key, or real key pointed only at a test address of your own	You rehearse real delivery against your own inbox, never against customers.
prod	The email service's production key	The email reaches the real customer. Final, no undo.

The key idea: in dev, no email ever leaves for the world. In staging you can rehearse real delivery, but against an address of your own, not against the customer list. Only in prod does a send reach a real customer. And the workflow is the same in all three: it references Email API, and the environment decides the destination.

Why it works: sending emails is the action from the "never against production" list that damages reputation fastest (it reaches a person, there is no recall). Designing its credential per environment applies the lesson to a new side effect, which is exactly what you are going to do with the CRM in lesson 8.

Exercise 3 — Classify what gets tested against production and what does not. For each action, say whether it can be tested directly against production or not, and why: (a) reading the CRM's customer list (read-only, no writes); (b) creating a new customer in the CRM; (c) checking the weather with a free public API; (d) issuing a tax invoice; (e) sending a Slack message to a #test channel you created yourself.

See solution

(a) Yes, it can (carefully) — it is read-only; reading pollutes nothing and destroys nothing. Still, spending real API quota just to test is a minor cost worth considering; if the provider has a sandbox, use it anyway. (b) No — creating a customer writes to production; it contaminates real data. Test it against the sandbox instead. (c) Yes, it can — it is read-only, against a free service, with no effects. Here a sandbox is unnecessary. (d) No, never — a tax invoice is one of the most irreversible actions there is: it has legal effects and cannot be "un-issued." Only with the tax provider's test mode. (e) Yes, with a caveat — the #test channel is yours and does not reach a customer, so it is a valid test destination you set up by hand (setup C: you built your own separation). Sending to the company's #general channel, on the other hand, would be production.

Why it works: the fire question —"can I undo it without anyone noticing?"— classifies all five. Reading and checking the weather: yes, no effect. Creating a customer, issuing a tax invoice: no, irreversible effect. Slack depends on who it reaches, and there you see that "production" is not a server, it is "wherever real effects land": a test channel you control is a sandbox even if it lives in the same company Slack.

Summary and next step

In this lesson you saw what a test account is —a service's model home: identical to the real one, but made of props— and what a sandbox key is —the key that opens the model home, Monopoly money instead of real money. You saw that serious providers give you two keys marked right in their own text (test/live, sandbox/prod) precisely so you do not confuse them, with a payment gateway's test mode as the most standardized example. You brought the pattern down to Cumbre's CRM and its three possible setups —separate sandbox account, test key inside the same account, or no native sandbox at all— and hooked the key into Module 4's per-environment credentials: the same order-triage workflow, without changing a single line, points at the sandbox in dev/staging and at the world in prod, because it is the environment —not the workflow— that decides the destination. And you locked in the hard rule of what never gets tested against production: charging money, sending messages to real people, writing or deleting real data, firing irreversible third-party actions —anything with no undo.

With this you check off the first point of the checklist: your test runs against sandbox keys, not against production.

Before moving on you should be able to: explain in one sentence the difference between a test key and a production key; describe why the same workflow can point at different destinations depending on the environment; and recite the fire question that decides whether something gets tested against production or not.

You now have the workflow connected to a safe destination. What it is missing is safe inputs. Lesson 3 gets into synthetic data: why you do not test with real customer data —privacy and personal information— how to generate fake but realistic orders with the Code node or with fixed datasets, and —most valuably— how to deliberately cover edge cases and dirty data, so your test resembles reality instead of just the happy case.

Resources

• Credentials — n8n Docs — how n8n stores and references credentials; the foundation for separating the test key from the production key by environment.
• Manage credentials — n8n Docs — creating and editing a credential on each instance, the concrete step this lesson covers.
• HTTP Request node — n8n Docs — the order-triage node that talks to the CRM and where the CRM API credential is selected.
• Stripe test mode — Stripe Docs — the canonical example of a test mode: sk_test_ keys, test cards, and a separate dashboard; check there for the exact details if you use Stripe.
• Environment variables in n8n — n8n Docs — how an environment defines its configuration, the foundation of Module 4's "one credential per instance" arrangement.