Test mode

The same API, the same records, the same refusals — with every side effect switched off.

What is real

A test key writes real rows. Create a customer with one and you can read it back, list it, ask for its readiness, and see it in your console. That is deliberate: a sandbox that forgets what you posted cannot be integration-tested, and the first thing anyone writes against a new API is a create-then-read test.

What is suppressed

No phone number is ordered and no money is spent.
No call is placed. No number rings, ever.
No email is sent to anyone outside your own account.

Test mode suppresses actions, not records. If a request would have cost you something, in test mode it costs you nothing and tells you what it would have done.

The two worlds never meet

Every read is filtered by the mode of the key that made it. A test key cannot see, list, modify or delete a live customer, and the reverse is equally true. There is no override parameter, so a test script pointed at production credentials by accident still cannot touch live data.

Responses carry x-kleos-mode: test or x-kleos-mode: live, and every customer object carries a mode field. Assert on it in your test suite.

Test mode is not a trial. It does not expire, and it is not a reduced feature set. You can build and maintain your entire integration in it indefinitely; going live changes which keys you deploy, not which code you wrote.

Readiness in test mode

The readiness endpoint answers honestly in test mode too: it will report emporos_not_live among the blockers, because that is true. It does not pretend a test customer is ready for a call it would refuse to make.