Production access

The sandbox opens on its own once your developer profile is complete; production is requested, reviewed by Noryo and decided. What the request contains, what an approval does, and the three conditions that come after.

View as Markdown

Transaction Intelligence opens in two stages: the sandbox is self-service, production access is requested.

The sandbox: self-service, once the developer profile is complete

Before an owner or an admin can enable the Transaction Intelligence sandbox on the API keys page, the workspace must carry a complete developer profile. It is an admission condition, not a formality: while anything is missing, enabling is refused and no key is issued.

The profile is filled in on Platform, by an owner or an admin, and holds for the whole workspace: a developer who later creates a key does not have to fill it in. It gathers your first and last name, a verified email, a professional phone number in international format, declared and not verified at this stage, your organisation's name (the one given by default when a workspace is created does not count as one), then four written answers: why Transaction Intelligence, what you are building, your use case, your integration context.

An incomplete profile returns the list of what is missing; complete it, then pick the Quickstart back up at its first step.

Production is not obtained through any sequence of actions

There is no button that moves a workspace from sandbox to production. Neither the number of keys created, nor the request volume read on the Usage page, nor the age of the workspace changes anything: those are measurements, not rights. Production opens through a decision by Noryo, taken on a request, or it does not open.

A Transaction Intelligence production request is separate from any request filed for another Noryo API: approving one does not approve the other.

What the request asks for

Item	What is expected
Legal identity	The legal name of the entity that will operate the integration, where there is one.
Product URL	The address where your product can be seen, even unfinished: a site, an application, a demonstration.
Production use case	What your product will do with enrichments once in service, described in prose rather than as a promise.
Expected volume	An order of magnitude of transactions per month, and what would make it move.
Expected users	Who calls, and for how many accounts: your own teams, your customers, your customers' customers.
Countries and markets	Where your users live and where the transactions you will send come from.
Data sources	Aggregator, bank connection, file import, entries from your own product: where the descriptors come from.
Integration architecture	Where the key lives, which service calls the API, what you keep of the response and for how long.
Production contact	A name, an email address and a phone number reachable while your integration is in service. That number will have to be verified.

Everything is described in text: the request accepts no file and no attachment.

What Noryo asks for, and what it never asks for

Noryo may, while your request is being handled, ask for a supporting item: a company registration, the identity of the representative, proof of address, your site's address, or another item that Noryo names. Such a request appears on Platform, on the Legal identity page, under "Supporting items requested", never in a standalone email. You answer with a reference to a document, never with the document itself: the portal receives none.

What is never sent, under any pretext, is a secret: a password, an API key, bank details, a card number, a code received by message. No request from Noryo covers any of these; if one does, do not answer it and write to support.

Nor should you pour your end users' data into the free-text fields: a use case can be described without a real transaction, without an IBAN and without a person's name. See Authentication.

The snapshot frozen at submission

A request is prepared as a draft, as many times as you need. At submission, Noryo freezes a snapshot of it: that is what gets reviewed, and nothing else. A later edit to the developer profile or the draft does not rewrite it.

To correct a request already submitted, withdraw it or wait for a request for further information: a new submission freezes a new snapshot without erasing the previous one.

The states of a request

State	What it means
Draft	Being prepared on your side: nothing has been sent, everything can be changed.
Submitted	The snapshot is frozen and the request is waiting to be picked up. The request can no longer be changed.
Under review	Noryo has picked it up and is reading it.
Further information requested	Something is missing: Noryo's message says what. You complete it, then submit again.
Approved	Noryo has decided in your favour. The next section says what that does, and what it does not do.
Rejected	Noryo has decided against. The reason is readable in the history.
Withdrawn	You have withdrawn your request. The request and its history remain.

Every move from one state to another is dated and kept: the history is never rewritten, and a decision never disappears, not even after a withdrawal.

What an approval does today

The word "approved" usually promises more than it holds here. An approval prepares the authority: it records, on Noryo's side, that your workspace is judged eligible for production. It is the first condition, and it does not stand for the ones that follow.

In particular, an approval:

issues no nry_txn_live_ key;
opens no production environment: https://api.noryo.app is still served as the sandbox;
opens no billing, accepts no contract on your behalf and sets no price;
changes neither the rate limits, nor the retention periods, nor the nature of the scores: see Sandbox limitations.

After approval: three decisions, three authorities

Next come, in this order:

The legal details. The identity of the entity, or the person, that will operate the integration, its address and a reachable contact. An owner or an admin fills them in on Platform; while anything is missing, the screen names it and the rest is refused. Someone building alone has no company to declare: their name and address are enough. The production contact's phone number must also be verified: someone in your organisation proves, on their Noryo identity, that they receive that number. A verified number says you can be reached there, nothing more: neither your legal identity, nor the power to bind a company.
The applicable API contract. Noryo publishes a version of it, carrying a reference and a fingerprint. An owner or an admin accepts it on behalf of the organisation, having attested that they hold the power to bind it; a developer, billing or viewer role cannot. If the text displayed does not match the text published, the acceptance is refused. Each acceptance is added to the history, none is rewritten.
Billing readiness. The system must be able to constitute and recover an amount owed for this workspace. That foundation now exists, but it is open for no customer workspace: no customer price is set, and no customer workspace is ready.

These three decisions do not stand in for one another: billing readiness, for its part, is not decided, it is observed. A nry_txn_live_ key is issued only once all three hold and the production authority has been neither suspended nor revoked.

The consequence is said without ambiguity: no production key can be issued today, for any customer workspace, since billing is not open. There is no announced price and no date. Until then, build against the sandbox.