OpenIRIS Public API

What is this?

OpenIRIS is getting a public REST API. Before we build it, we’re sharing the proposed contract so the people who’ll actually use it — institutional IT, lab admins, ELN vendors, university researchers — can read it, push back, and ask for the things we missed.

Nothing here is live yet. URLs like https://api.openiris.io/v1/… are the future surface, not a deployment. Schemas, field names, and scopes are open for change.

Who is this for?

I’m a researcher

Interested in whether your ELN or workflow tools will be able to pull data out of OpenIRIS.

/v1/bookings — what you’ve booked and when
/v1/resources — equipment catalog
/v1/calendar-feeds — iCal feeds for your personal calendar
/v1/attachments — files attached to bookings
/v1/form-submissions — structured data your facility collects

I’m a provider or org admin

Responsible for what your institution’s integrators get access to.

Authentication — API key model, scopes, multi-provider/multi-org grants
/api-keys (Internal) — key management from the admin UI
/v1/charges — billing export for your finance system
/v1/webhooks — event subscriptions replacing email noise
Audit log on every authenticated call

I’m on the integration team

Planning to build against this for your institution, vendor product, or research platform.

Auth: API keys with oi_live_… format, scoped per provider
/v1/charges + /v1/charges/{id}/exports — ERP sync (SAP Journal Entry compatible)
/v1/webhooks + /v1/events — HMAC-signed event delivery
Cursor pagination, filter[field][op]= operators, RFC 9457 errors
Idempotency-Key, ETag/If-Match, rate limiting

Explore the spec

The full OpenAPI 3.1 specification covers 23 resource groups. Priority areas (authentication, charges, bookings, resources, webhooks, events) are fully detailed with schemas and examples; other groups are at path + summary level while the details firm up.

Explore the API spec → Download openapi.yaml Leave feedback on UserVoice →

What we’re most interested in hearing

For ERP / billing integrators

Will the charge shape (currency as ISO 4217, tax per line, external_reference for dedup, *_local timestamps for fiscal period safety) transform cleanly into your system’s Journal Entry or invoice format? Anything missing that will force us to add columns later?

For ELN / workflow vendors

Is the external_reference pattern on bookings and requests the right round-trip primitive? Do the form-submission entity-reference types cover the experiment ↔ booking linkage you need? Are there webhook events we’re missing from the catalogue?

For institution admins

Does the multi-provider + multi-organization key model match how your IT team wants to manage integrations? Is the organization-scoped grant (auto-expands as the org adds providers) the right convenience, or do you want explicit control?

How to give feedback

We’re collecting comments on a dedicated UserVoice forum — anonymous posts are welcome, no account needed. If your feedback is about a specific endpoint (e.g. /v1/charges) or field (cost_center.provider_code), mention it in the title. If you integrate from a particular ERP, ELN, or lab system, say which — it helps us weigh tradeoffs.

Leave feedback on UserVoice →

Prefer email? Reach the API team at api-preview@openiris.io (pending setup — UserVoice is the primary channel while we validate).

Timeline

This is a proposal. No launch date is committed. We expect to iterate on the contracts based on feedback collected here for several weeks before we start implementation. Once we ship, the contract this page describes becomes v1 — stable under an additive-only versioning policy (breaking changes ship as v2, never as a silent update).