API reference (read-only)
Another system — for example your existing eQMS — can read your organization's risk assessments from Indelio with an API key. A key can only read; it cannot create, change or sign anything. Each key expires within a year, and revoking one is immediate and permanent.
Keys are issued inside Indelio by an administrator of your organization, under Settings → API access (read-only) → API keys. A key reads only its own organization's records.
Version 1 is read-only and serves risk assessments: each assessment, its risk items and its signatures. Nothing from any other module is served, and neither are the post-market review records themselves.
Getting a key
- An administrator opens Settings → API access (read-only) → API keys.
- Name the key after the system that will use it, choose when it expires (up to a year), and select Issue key.
- Copy the key straight away. It is shown once and Indelio does not keep a copy — store it in the calling system's secret store, the way you would a password.
To stop a key, select Revoke…, give the reason, and select Revoke permanently. It stops working on its next request and cannot be reactivated.
Sending a request
Send the key in the Authorization header of every request. Responses are JSON: { "api_version": "1", "data": … }. An error is JSON too: { "error": "…", "message": "…" } — branch on error; the message is written for a person reading a log. Timestamps are UTC, ISO 8601. Requests are limited to 60 a minute from one address.
Endpoints
/risk/assessments: Every assessment in the key's organization, newest code first. state is optional: one of Draft, In Review, Pending Approval, Approved, Cancelled./risk/assessments/{code}: One assessment. It adds its conclusion, integrity, signatures and items to the fields the list returns.
Example
One assessment, with the key read from an environment variable rather than typed into the command:
The answer (a fictional assessment; the real endpoint returns exactly this shape):
The same request with no key is refused with 401:
Responses
200- The data.
400- A query value is not allowed (for example an unknown state).
401- No key was sent, or the key is not valid for this request — unknown, revoked, expired, or for an organization that is suspended. The response does not say which.
404- No assessment with that code in the key's organization.
429- Too many requests: more than 60 in one minute from the same address. Wait for the minute to pass, then retry. The limit is enforced by Indelio's hosting firewall, before the request reaches Indelio, so the body is the firewall's rather than the format above.
500- Something unexpected went wrong in Indelio. Nothing about your key is implied; retry later, and tell us if it persists.
503- Indelio could not complete the request. Nothing about your key is implied; retry after the Retry-After interval.
error: bad_requesterror: missing_api_key or invalid_api_keyerror: not_founderror: internal_errorerror: service_unavailableAssessment (list and single)
codestring- The assessment's number in Indelio, e.g. RA-004. Stable; use it to fetch one assessment.
titlestring- The assessment's title.
statestring- Draft, In Review, Pending Approval, Approved or Cancelled.
methodstring | null- The risk-management method recorded, e.g. ISO 14971.
scopestring | null- What the assessment covers.
ownerstring | null- The owner's name.
created_attimestamp- When the assessment was created (UTC, ISO 8601).
updated_attimestamp- When it last changed.
last_reviewed_attimestamp | null- When its last post-market review was recorded.
next_review_duetimestamp | null- When its next periodic review is due.
review_interval_monthsnumber- The periodic review interval.
item_countnumber- How many risk items it holds.
high_residual_countnumber- How many items remain High after risk control.
Assessment (single only)
overall_conclusionstring | null- The overall conclusion on residual risk.
content_hashstring- SHA-256 of the assessment's material content. Its signatures are bound to this value.
integritystring- "intact" when the content still matches its content hash, "changed" when it does not.
signaturesarray- Each electronic signature on the assessment (fields below).
itemsarray- The risk items, in item-number order (fields below).
Signature
meaningstring- What the signature means, e.g. "Approved by".
signer_namestring- The signer's printed name, captured at signing.
signed_attimestamp- When it was signed (UTC).
bound_to_current_contentboolean- true when it was applied to the content as it is now; false when the assessment changed after signing.
Risk item
numbernumber- The item's own number, as the audit trail records it. Never reused after an item is removed.
domainstring | null- The design domain, e.g. Cyber.
hazardstring- The hazard.
sequence_of_eventsstring | null- How the hazard would reach someone.
hazardous_situationstring | null- The hazardous situation.
harmstring | null- The harm.
severitynumber- Initial severity, 1–5.
probabilitynumber | null- Initial probability, 1–5 (when scored by probability).
exploitabilitynumber | null- Initial exploitability, 1–5 (Cyber items scored by exploitability).
likelihood_basisstring- "probability" or "exploitability" — which score the levels use.
cvss_scorenumber | null- CVSS base score, where recorded.
cvss_vectorstring | null- CVSS vector, where recorded.
initial_levelobject- { score, band } before risk control; band is Low, Medium or High.
risk_controlstring | null- The risk control measure.
control_optionstring | null- The ISO 14971 §7.1 option chosen.
option_rationalestring | null- Why stronger options were not practicable.
control_refstring | null- Reference to the control's implementation.
residual_severitynumber | null- Severity after risk control.
residual_probabilitynumber | null- Probability after risk control.
residual_exploitabilitynumber | null- Exploitability after risk control.
residual_levelobject | null- { score, band } after risk control; null until residual risk is scored.
verificationstring | null- How the control's effectiveness was verified.
acceptabilitystring | null- The acceptability decision.
Looking after a key
- Keep it in the calling system's secret store — never in a URL, a code repository, a ticket or an email.
- Issue one key per system, so one can be revoked without stopping the others.
- Revoke a key as soon as it may have been exposed, or when the system or the person responsible for it leaves.
- Issue a replacement before a key expires; an expired key stops working without warning to the caller.