A certificate is a durable, independently checkable record that a notification under Engineering Recommendation G98 (“connect and notify”) was submitted to a named distribution network operator, for a named property, on a named date, under the application reference the ENA Connect Direct platform returned.
It is issued at the moment a filing succeeds, it is not tied to any account, and checking one requires no login, no relationship with OurOrb Energy and no payment.
A certificate exists only where a notification was actually filed. Where a notification could not be submitted through Connect Direct - and the customer was given documents to send to their network operator themselves - no certificate is issued, because there is nothing yet to attest.
Precisely these things, and nothing beyond them:
A certificate id is crt_ followed by 32 lowercase hexadecimal characters - 128 bits of entropy.
The identifier is the access control. There is no lookup by address, postcode, name or owner. There is no list endpoint, and no search. A certificate can be checked only by someone who has been given its id.
This is a deliberate design decision, not a missing feature. A searchable register of which properties have generation installed is a different product carrying different obligations, and this is not that product. Unknown ids and malformed ids are answered identically, so checking an id reveals nothing beyond what holding it already proves.
Every certificate carries a mode.
Mode resolution fails closed. Where a certificate’s mode cannot be established with certainty it is recorded as test. A certificate may understate itself; it will never overstate itself. On the verification page a test certificate receives this warning treatment instead of the confirmation - never alongside it, because a confirmation with a caveat underneath is how a screenshot misleads someone.
Every certificate records the family of device its notification covers, and the class is part of the published record in section 9 from version 1.4.
It was previously withheld, on the stated reasoning that a field carrying the same value on every certificate tells a verifier nothing, together with an undertaking to publish it when a second class was first issued. Battery storage files as generation_demand - a battery both generates and draws - so a second class now exists and that undertaking has been met. Every certificate issued before 10 September 2026 reads generation, which is what those installations were.
Further classes are reserved for other device families. A class is only issued once the wording appropriate to it has been settled, because “submitted, never approved” is true of connect-and-notify processes and is not true of processes that involve an application and an approval. A certificate will never carry wording that is wrong for the process it describes.
A certificate that turns out to be wrong is revoked, not deleted. A revoked certificate keeps resolving and keeps serving its record, marked as withdrawn with the date and, where one was given, the reason.
This is deliberate. Someone holding the id learns that the certificate was withdrawn, rather than meeting a “not found” that could equally mean they mistyped it. Only the first revocation takes effect: a certificate cannot be un-revoked, and a revocation reason cannot be rewritten afterwards.
No MPAN. No name. No email address. No telephone number. No payment information. No copy of the submitted form.
A certificate holds only the fields listed in section 9 - the minimum that makes it useful to someone checking it. The underlying submission record does contain personal data, and is anonymised 90 days after it is created; a certificate survives that because it holds nothing requiring erasure. A certificate cannot be issued after that anonymisation has run.
That asymmetry is the design, not a side effect. The personal data behind a notification has a deliberately short life; the record that the notification happened does not. A certificate issued today is intended to still resolve, and still say the same thing, long after every personal detail behind it has been erased - which is the case a permanent record has to be able to make.
The verification page and the machine-readable endpoint serve the same projection, so the human answer and the software answer cannot diverge.
| id string | The certificate identifier (see section 4). |
| mode live | test | Which ENA environment the notification was filed to (see section 5). |
| applicationId string | The application reference returned by ENA Connect Direct. |
| dnoName string | The distribution network operator the notification was submitted to. |
| addressLine1 string | First line of the installation address. |
| postcode string | Postcode of the installation address. |
| deviceClass generation | demand | generation_demand | Which family of device the notification covers. generation is generating plant such as solar PV; generation_demand covers battery storage, which both generates and draws. Every certificate issued before 10 September 2026 reads generation, which is what those installations were. |
| systemWatts number | null | Declared total system output in watts, where recorded. |
| productName string | null | The declared inverter manufacturer and model, where recorded. |
| tenantDisplayName string | The organisation that filed the notification. |
| installedBy string | null | The business declared as having carried out the installation, where one was named. This is not the same claim as tenantDisplayName above: it names who did the work, not who submitted the notification, and unlike that field it is a declaration we have not verified (see section 3). Absent when the installation was self-installed, when no business was named, or where only an individual was given - an individual’s name is never published here. |
| filedAt ISO 8601 | When the notification was submitted. |
| issuedAt ISO 8601 | When this certificate was issued. |
| revokedAt ISO 8601 | null | When the certificate was withdrawn, if it was (see section 7). |
| revokedReason string | null | The reason for withdrawal, where one was given. |
| cdStatus string | null | The network operator’s own status for the application, reproduced verbatim when known. This is the operator’s statement, not OurOrb Energy’s, and its absence means only that no status has been published. |
As a person. Open https://verify.ourorb.energy/check/{id}, or paste the id - or a whole certificate link - at /check.
In software. GET https://api.ourorb.energy/v1/certificates/{id} returns the section 9 record as JSON with HTTP 200. No API key, no account, no charge. Cross-origin browser requests are permitted. Unknown or malformed ids return 404. Responses may be cached for up to 60 seconds, so a withdrawal propagates within a minute.
Verification is free and unmetered by design. A verification layer that required an account would only ever be checked by our own customers, which would defeat the point of having one.
This specification is versioned. Changes are additive: new fields and new device classes increment the minor version, and anything already defined keeps the meaning it had. If a definition ever had to change meaning, that would be a new major version, and certificates would continue to be interpreted under the version they were issued against.
The behaviour described here is what the software does. Where this document and the software could ever disagree, that is a defect in one of them - please report it.
Questions about this specification, or about a certificate you have been given: hello@ourorb.energy.
Proof of Notification specification v1.4, 10 September 2026. Engineering Recommendation G98 is published by the Energy Networks Association. OurOrb Energy is not affiliated with the Energy Networks Association or with any distribution network operator.