Share portals
A link you give the vendor on the other end of an interface. They can read your spec, test their own messages against it, and see what changed between versions - without an account, and without you emailing a PDF that is stale the day after you send it.
What a portal is
The usual way this goes: you write an interface specification, email it, and then spend three weeks answering "is this right?" over email with sample messages pasted into the body. The vendor cannot check their own work, so you become the validator.
A portal is the same spec as a page they can use. It always shows the published production version, so what they are reading is what they will be held to.
Create a link
Open a spec, then Share. You give the link a label - usually the vendor's name, so you can tell them apart later - and optionally an expiry. You get a URL of the form:
https://www.interoperall.com/s/<token>
The token is 24 random bytes. It is the only credential, so treat the link itself as the secret: anyone holding it can read the spec.
What the vendor sees
The Validate tab is the point of the whole thing. It turns "send me a sample and I will check it" into something they do themselves, before they send you anything.
Validating over the API
The same token works as an API endpoint, so a vendor can wire your spec into their own build rather than checking by hand:
curl -X POST https://www.interoperall.com/api/v1/validate/<token> \ -H "Content-Type: text/plain" \ --data-binary @sample.hl7
The response is a structured pass/fail report - status, score, and a result per rule. Rate is per your plan, not per vendor: a token handed to three vendors draws on one budget, because the limit belongs to the plan paying for it.
Versions
A portal tracks your published production version. When you publish a new one the portal follows, and the version history tab shows the vendor what moved.
To hold a vendor to a specific release - the one in the contract - pass ?version=1.2.3 to the API endpoint. That pins the check to a published version regardless of what production has since become.
Branding
A portal carries your organisation name, logo, colour, cover subtitle, footer text and a contact link, set per spec. It is the difference between sending someone a tool and sending them your interface specification. Branded portals are on the paid plans.
Expiry and revocation
A free plan cannot create share links, so a downgrade leaves existing links readable but stops you making new ones - nothing is deleted.
Coverage and probe portals
Two other things share the same way. A FHIR coverage report publishes to /c/<token> and a conformance probe scorecard to /p/<token>. Both are read-only snapshots, useful for handing a supplier an assessment of their FHIR server that they can read without an account.
What a portal exposes
A portal shows the spec - which includes the examples saved in it. If you have saved real messages as regression tests, those are part of the document a portal holder can read. Use synthetic or de-identified messages as examples on any spec you intend to share.
Messages a vendor pastes into the Validate tab are validated in their own browser. What we record for a portal is the same metadata as any validation - counts, timings, outcome - never content. See trust & data handling.