# endpoint REST del Test Catalog
**URL:** https://talk.openelis-global.org/t/endpoint-rest-del-test-catalog/2409
**Category:** Uncategorized
**Created:** [September 3, 2026, 4:22pm UTC](https://talk.openelis-global.org/t/endpoint-rest-del-test-catalog/2409 "2026-09-03T16:22:19Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@luis.uriarte](https://talk.openelis-global.org/u/luis.uriarte)
#### Post date: [September 3, 2026, 4:22pm UTC](https://talk.openelis-global.org/t/endpoint-rest-del-test-catalog/2409/1 "2026-09-03T16:22:19Z")
Hello,
Yes, I meant to post this question on OpenELIS Global Talk. Thank you for pointing me in the right direction.
I am working on an integration between OpenELIS Global and OpenEMR. My goal is to access the OpenELIS test catalog programmatically, including information such as:
- Test ID
- Test name
- Test description
- Test section
- Sample type
- Units
- Active/inactive status
- Other related catalog information
I understand that there has been work on exposing the Test Catalog through a REST endpoint.
Could you please provide information about:
1. The REST endpoint(s) currently available for accessing the Test Catalog.
2. Whether the endpoint is already available in the `develop` branch.
3. The authentication method required to access it.
4. Whether it is possible to create a dedicated API/service user with read-only access.
5. Any available documentation, OpenAPI/Swagger definition, or examples.
I am currently running OpenELIS Global 2 from the `develop` Docker images.
The purpose is to synchronize or query the OpenELIS Test Catalog from OpenEMR without accessing the PostgreSQL database directly.
Thank you very much.
---
### Author:  [@wodpachua](https://talk.openelis-global.org/u/wodpachua)
#### Post date: [September 4, 2026, 8:44am UTC](https://talk.openelis-global.org/t/endpoint-rest-del-test-catalog/2409/2 "2026-09-04T08:44:03Z")
Hloo @luis.uriarte
Incase u havent already… you could try `GET /OpenELIS-Global/rest/TestCatalog` from [here](https://github.com/DIGI-UW/OpenELIS-Global-2/blob/f07ba0775fba9ea679bafe230c5070284462ec42/src/main/java/org/openelisglobal/testconfiguration/controller/rest/TestCatalogRestController.java#L55)? It seems to already be in develop… with the fields it fills as u want all there, [see](https://github.com/DIGI-UW/OpenELIS-Global-2/blob/develop/src/main/java/org/openelisglobal/testconfiguration/controller/rest/TestCatalogRestController.java#L101C1-L115C61).
There is also a newer &paged one under `/rest/test-catalog/tests` [here](https://github.com/DIGI-UW/OpenELIS-Global-2/blob/f07ba0775fba9ea679bafe230c5070284462ec42/src/main/java/org/openelisglobal/testcatalog/controller/rest/TestCatalogEditorRestController.java#L212)
And about the auth question, i think plain http basic should do, and i see both classes are also gated at the top.. i wonder if these cover u needs?
---
### Author:  [@luis.uriarte](https://talk.openelis-global.org/u/luis.uriarte)
#### Post date: [September 4, 2026, 1:13pm UTC](https://talk.openelis-global.org/t/endpoint-rest-del-test-catalog/2409/3 "2026-09-04T13:13:57Z")
Hi. Thank you so much.
@wodpachua, this was incredibly helpful. What I need to figure out now is that the user accessing the system must have the Global Administrator role (I don’t like that).
Thanks again, my friend.
---
### Author:  [@wodpachua](https://talk.openelis-global.org/u/wodpachua)
#### Post date: [September 4, 2026, 2:14pm UTC](https://talk.openelis-global.org/t/endpoint-rest-del-test-catalog/2409/4 "2026-09-04T14:14:23Z")
Hloo @luis.uriarte
Glad it helped…
the other direction could be widening the gate itself.. i see other controllers already doing `hasAnyRole(...)`..
@Moses_Mutesasira @Agaba_Derrick_Junior what would be ur take on this one? would u say widening the catalog GETs to `hasAnyRole` be something acceptable, or is a read-only role already planned somewhere??
---
### Author:  [@luis.uriarte](https://talk.openelis-global.org/u/luis.uriarte)
#### Post date: [September 7, 2026, 5:46pm UTC](https://talk.openelis-global.org/t/endpoint-rest-del-test-catalog/2409/5 "2026-09-07T17:46:09Z")
> [@wodpachua](#):
>
> Thanks for the quick response and for bringing this up with the team.
>
> I completely agree that widening the GET endpoints or introducing a dedicated read-only / API integration role would be the best approach. Requiring full `ADMIN` privileges just to fetch reference data like test catalogs goes against the principle of least privilege, especially when managing automated system-to-system integrations.
>
> Having a dedicated `ROLE_API_READ` (or expanding `hasAnyRole` on GET catalog endpoints) would allow us to safely query metadata using restricted service accounts without exposing administrative capabilities.
>
> Looking forward to hearing thoughts from @Moses_Mutesasira and @Agaba_Derrick_Junior on this!
Thanks for the quick response and for bringing this up with the team.
I completely agree that widening the GET endpoints or introducing a dedicated read-only / API integration role would be the best approach. Requiring full `ADMIN` privileges just to fetch reference data like test catalogs goes against the principle of least privilege, especially when managing automated system-to-system integrations.
Having a dedicated `ROLE_API_READ` (or expanding `hasAnyRole` on GET catalog endpoints) would allow us to safely query metadata using restricted service accounts without exposing administrative capabilities.
Looking forward to hearing thoughts from @Moses_Mutesasira and @Agaba_Derrick_Junior on this!
---
### Author:  [@Agaba\_Derrick\_Junior](https://talk.openelis-global.org/u/Agaba_Derrick_Junior)
#### Post date: [September 7, 2026, 7:42pm UTC](https://talk.openelis-global.org/t/endpoint-rest-del-test-catalog/2409/6 "2026-09-07T19:42:23Z")
Hi [@luis.uriarte](https://talk.openelis-global.org/u/luis.uriarte), [@wodpachua](https://talk.openelis-global.org/u/wodpachua),
Thanks for tagging me on this,I think you’re both landing on the right instinct.
Widening the existing gate to `hasAnyRole(...)` with current admin-adjacent roles would work as a quick fix, but I’d rather we not just fold API integrations into roles that carry other permissions they don’t need. A dedicated read-only role (something like `ROLE_API_READ` or `ROLE_CATALOG_READ`) is the better long-term design:
- It keeps service accounts scoped to exactly what they need, no more, no less.
- It makes it easy to tell from config/logs which accounts are machine integrations vs. human admins.
- We already have precedent for `hasAnyRole(...)` gating elsewhere in the codebase, so this isn’t a new pattern, just a new role added to it.
- As more systems (OpenEMR and others) want to pull reference data, this saves us from repeatedly loosening admin’s implicit surface area.
I don’t think a read-only role is currently planned as far as I know, happy to be corrected if someone’s already working on it. If not, I’d suggest we scope this as a small, contained change: introduce the role, annotate the catalog GET endpoints (`TestCatalogRestController` and `TestCatalogEditorRestController`) with `hasAnyRole("ROLE_ADMIN", "ROLE_API_READ")`, and document how to provision a service account with just that role.
[@luis.uriarte](https://talk.openelis-global.org/u/luis.uriarte), if that direction works for you, I’m happy to help in other way.
---
### Author:  [@luis.uriarte](https://talk.openelis-global.org/u/luis.uriarte)
#### Post date: [September 7, 2026, 9:43pm UTC](https://talk.openelis-global.org/t/endpoint-rest-del-test-catalog/2409/7 "2026-09-07T21:43:58Z")
@Agaba_Derrick_Junior_Thanks for the quick and thoughtful response — `ROLE_API_READ` sounds like the right direction to me too, for exactly the reasons you listed (scoped service accounts, clearer audit trail as more systems start pulling catalog data)._
_I don’t have deep familiarity with the codebase yet (I came in through the OpenEMR integration side), so I’ll hold off on committing to drive the implementation myself for now — but I’m glad to help test against a real deployment once there’s something to try, or pick up smaller pieces if that’s useful. Appreciate you looking into it either way._
Luis