# Smart on openEHR OpenAPI
**URL:** https://discourse.openehr.org/t/smart-on-openehr-openapi/4857
**Category:** ITS
**Created:** [25 January 2024 15:05 UTC](https://discourse.openehr.org/t/smart-on-openehr-openapi/4857 "2024-01-25T15:05:48Z")
**Posts on this page:** 4
**Page:** 1
### Author:  [@joostholslag](https://discourse.openehr.org/u/joostholslag)
#### Post date: [25 January 2024 15:05 UTC](https://discourse.openehr.org/t/smart-on-openehr-openapi/4857/1 "2024-01-25T15:05:49Z")
> - `openapi`: A URL to the OpenAPI specification of the service
> …
With example:
```auto
"openapi": "https://platform.example.com/openehr/rest/v1/openapi.json"
```
At:
> **[SMART on openEHR (SMART)](https://specifications.openehr.org/releases/ITS-REST/latest/smart_app_launch.html#_services)**
>
> openEHR SMART App Launch and Service Discovery Framework (SMART)
Why doesn’t the OpenAPI always point to openEHR OpenAPI files at [specifications-ITS-REST/computable/OAS at master · openEHR/specifications-ITS-REST · GitHub](https://github.com/openEHR/specifications-ITS-REST/tree/master/computable/OAS)
They shouldn’t be vendor/server specific right?
---
### Author:  [@Sidharth\_Ramesh](https://discourse.openehr.org/u/Sidharth_Ramesh)
#### Post date: [26 April 2024 07:15 UTC](https://discourse.openehr.org/t/smart-on-openehr-openapi/4857/2 "2024-04-26T07:15:38Z")
We’ve redirected it to the ITS-REST page for now ([openEHR - REST API specifications (ITS-REST) Component - latest](https://specifications.openehr.org/releases/ITS-REST/latest)), but this could be a mistake. @sebastian.iancu what do you think? Should we change this link to what @joostholslag is suggesting?
---
### Author:  [@sebastian.iancu](https://discourse.openehr.org/u/sebastian.iancu)
#### Post date: [4 May 2024 12:19 UTC](https://discourse.openehr.org/t/smart-on-openehr-openapi/4857/3 "2024-05-04T12:19:54Z")
I thought that the idea is that discovery is always real to a real life implementation inside the playform. So it is not about a generic (abstract) openapi spec but rather the exact one provided by the platform service. For sure, for conformance perspective this supposed to be 100% aligned with specification, but inreality they might not (for instance when at least that vendor is supporting more serializations formats, more endpoints, various flavours on headers , etc).
Also you have to imagine that in time we will have more version of the spec published, but a vendor implementation always supports a spannor versions or functionality (perhaps does not support latest version).
As a consumer application I would like to see what exists on service side, not what suppose to exist.
Does it make sense to you also?
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [4 May 2024 14:19 UTC](https://discourse.openehr.org/t/smart-on-openehr-openapi/4857/4 "2024-05-04T14:19:54Z")
The text at that link has this:
> A response from the SMART Configuration endpoint should include besides the [FHIR metadata](https://www.hl7.org/fhir/smart-app-launch/conformance.html#metadata) also a hash of all available `services` on the _Platform_. The `services` section allows the application to discover the APIs of all services that can be used along with their description and documentation. The `services` section is represented as a hash, where the key is represented by a reverse domain name of the service (e.g. `org.openehr.rest`), and the value represents the service specification.
In the above the term ‘hash’ is used to what I assume is really a ‘map’ (could be implemented by a hash table). The term ‘hash’ on its own usually means cryptographic hash, e.g. SHA-256 or similar.
I suggest changing ‘hash’ to ‘map’ in this document.