Skip to main content
Your company integrates and runs a customer’s agents, and the data is theirs. This guide sets the project up the way the law expects: the controller named, its decisions taken by a link with a code in its DPO’s e-mail, and your company’s access reviewed every 90 days. The concepts are in Parties and approvals.

​
Before you start

  • A Console person token of your tenant, with the admin role for the entities and parties and security for the configuration diffs. In the examples, NIADRA_TOKEN, against the control API at https://control.api.niadra.com.
  • The project id (PROJECT_ID) and, for the diffs, the production space’s id (SPACE_ID).
  • The name, country, registry number and data protection officer’s e-mail of both companies: yours and the customer’s. The customer’s DPO e-mail is where the links go; confirm it with them first.

​
1. Register both companies

The answer carries entity_id, the registry masked and never the e-mail. Register your own company the same way. A second call with the same registry and the same e-mail answers the entity that already exists; with another e-mail, 409, because a company’s DPO does not change by a request.

​
2. Name the controller and the operator

With the controller named, the project starts waiting for it. Adding your company as operator now answers 409 controller_approval_required: request the approval and repeat the call once it approves.
The answer is the approval, pending, with approval_id, document_hash and expires_at. The link went to the controller’s DPO e-mail and is not in the answer.

​
3. What the DPO sees

The link opens the Console’s public approval page. It shows what is asked, by which tenant and for which project; the DPO asks for the code, gets six digits in the same e-mail, opens the document and decides. Five codes per link, one a minute; five wrong codes close the link, and an expired or used link answers like one that never existed. The decision is made once and becomes a receipt in the project’s spaces. Follow it through the API:
When the status is approved, repeat step 2 for the operator. An expired approval needs a new request.

​
4. Diffs that wait for the controller

A configuration diff that widens the space’s purposes, loosens the access policy or extends a retention does not take effect when approved in your Console: it stays pending until the controller approves. Submit the diff as usual, through the Configuration screen or POST /v1/config/diffs, and request the approval with its id:
The other diffs, the ones that restrict or only change operations, take effect as they always did. The control plane checks this when the diff is submitted and again when it is approved.

​
5. The impact report

Generate the report for each purpose of the space and request its approval. Since the report is stable, the controller approves a hash, and the read says when it approved this very document:
A configuration that changed since generates another document, with another hash and no approved_at: request again.

​
6. The access review

Every 90 days, the controller confirms that your company’s access stays as it is. The control plane asks for the review by itself when it falls due; you follow it at:

​
7. An incident out of hours

When someone needs a role they do not have, now, without waiting for a link:
The role applies on the next token, for at most four hours. The controller is told by e-mail and can end the access by the link, and it is recorded as an approval of kind emergency_access, with the reason.

​
8. Passing the operation to another company

When the customer changes operator, the new operator requests the transfer, after the controller approves transfer with the new operator’s tenant id as subject:
The space databases stay where they are: the customers’ memory continues. Your source keys keep working for 72 hours and expire at grace_until; the answer lists, per space, the webhook endpoints whose secrets the new operator must turn before then, with PUT /v1/secrets/webhook/{id}. An endpoint still signing with a secret of yours stops receiving when the grace period ends.

​
What is recorded

Every decision, every emergency access and every transfer enters the receipt chain of the project’s spaces, which the controller can audit through its own chain. In the Console, the Project and controller screen, of the security role, shows the parties, the pending and decided approvals, the access review and the transfers, and the Companies screen shows the tenant’s legal entities.

​
Next steps

Parties and approvals

the model behind each step.

Console access

the roles each route asks for.

Receipts and audit

where each decision is recorded.

List approvals

the reference of GET /v1/projects/{project_id}/approvals.