Our own eLabFTW instance
We provision and maintain a private instance on a selected supported release. Synthetic teams, users, resources and experiments provide all development fixtures, with our own keys, reset and backup procedures.
Proposed planFor Charité / eLabFTW integration
Public API,
ready for integration.
A tested, documented Public API and eLabFTW connector, built independently on our own environment and ready for Charité to adopt.
Explore the delivery timelineBuild and test independently. We provide the eLabFTW environment, test data, connector and acceptance evidence. Development proceeds without waiting for Charité; connecting to their own installation is a separate, focused deployment step. The proposed delivery window remains 2 November–7 May.
One plan. Seven delivery milestones.
Select a milestone to see the deliverables and evidence of completion.
Planned workAcceptance target
Scroll sideways to view the full November–May timeline.
Milestone and target date
Nov 2026DecJan 2027FebMarAprMay
Work windows and acceptance dates are planning targets; they do not show completed work.
Shaded interval: reduced capacity over 19 Dec–3 Jan.
Built and tested on our own setup
We provide the environment, connector, test data and QA. Charité does not need to supply servers, test accounts or workshops before development can proceed.
A standard integration baseline
We define the initial workflow and safe identity/permission rules using existing requirements. Assumptions are documented; partner feedback can refine them without stopping development.
First working experiment link
Our connector links an existing OpenIRIS booking and resource to an eLabFTW experiment, reads it back and opens both records. Several bookings can link to one experiment without replacing scientific content.
Booking lifecycle and rules
We deliver the prioritised booking operations through shared pricing and rules, with parity checks. OpenIRIS remains the booking authority; rescheduling and additional surfaces follow the internal v1 baseline.
Reliable connector operation
Durable links, polling, retries and reconciliation are tested on our setup, including timeouts, duplicates, locked records and outages. eLabFTW event support is used only when verified on a supported version.
Our own acceptance evidence
Our QA team runs real-SQL parity and real-eLabFTW end-to-end tests. March delivers qualification and a ready-to-show demonstration; a partner walkthrough or local compatibility check can happen alongside this work.
No Charité dependency on the development critical path. We set the baseline and estimate the work in November, proceeding with documented defaults where local details are unknown. Installation-specific checks happen when connection details are available. The May delivery target covers the Public API, tested connector and handover.
Technical references: eLabFTW hosting prerequisites · API access · API v2 reference
What each milestone delivers
Each phase ends with a result that can be demonstrated and accepted.
01Delivery baseline and test plan2–20 Nov 2026Target 20 Nov 2026
An OpenIRIS-owned delivery baseline, standard integration contract and test plan, ready to execute independently.
What we will deliver
- Use existing member use cases to define the initial workflow, fields and acceptance scenarios; record assumptions and proceed without waiting for Charité workshops or sign-off.
- Select and pin a supported eLabFTW release for our own instance; document the supported-version baseline and any known compatibility limits.
- Define safe default identity, booking-permission and record-mapping rules. Keep OpenIRIS as the booking authority.
- Take ownership of connector development and the private instance, estimate the work and prioritise v1 internally. Begin setup with synthetic data.
02API onboarding and private test instance23 Nov–18 Dec 2026Target 18 Dec 2026
Working API access and our own private eLabFTW environment are ready for January testing.
What we will deliver
- Complete API key management, separation of test and live keys, and clear onboarding instructions.
- Bring our private eLabFTW instance online on the selected pinned version, with secure access, test keys, synthetic teams/users/experiments and a repeatable reset.
- Validate existing resource, booking, request, directory and charge data against deployed OpenIRIS environments; smoke-test both systems’ API access.
- Prepare monitoring, release and rollback procedures; deliver a controlled initial release after compatibility and quality checks pass.
03Booking workflows and eLabFTW link4–29 Jan 2027Target 29 Jan 2027
A real experiment-to-booking link works on our own setup, with core reservation operations ready for testing.
What we will deliver
- Demonstrate a connector that links an existing OpenIRIS booking and resource to an eLabFTW experiment, reads the link back and opens the related records.
- Implement durable user, resource and experiment mappings, permission checks and several-bookings-per-experiment support without overwriting notebook content.
- Complete shared pricing and booking rules, advance reservations, cancellation and required supporting data; begin rescheduling if included in the internal v1 baseline.
- Run repeatable real-database and eLabFTW end-to-end tests using our own identities and synthetic fixtures.
04API and connector feature complete1–26 Feb 2027Target 26 Feb 2027
The v1 API and connector are ready for independent integration qualification.
What we will deliver
- Complete baseline request and booking workflows, including rescheduling if selected, with parity checks against existing OpenIRIS behaviour.
- Complete connector polling, durable link storage, retry queues, reconciliation and diagnostics; recover from partial failures without duplicate bookings or records.
- Deliver OpenIRIS event notifications and signed webhooks where required; verify eLabFTW capabilities against our pinned supported version.
- Finish only the forms, attachments or bulk operations selected internally for v1; publish the reference, connector instructions and examples.
05Integration qualification and demo1–26 Mar 2027Target 26 Mar 2027
The integration is qualified on our own environment and ready for a short partner demonstration.
What we will deliver
- Run the full integration and supported-version test pack on our private instance, using realistic synthetic teams, users, experiments and bookings.
- Test identity and provider isolation, private or locked experiments, booking changes, duplicate submissions, time zones and outage recovery.
- Prepare a recorded demonstration and a self-service installation/configuration checklist. Offer a short Charité walkthrough and check their environment if access is available.
- Resolve defects found by our tests and freeze the release scope. Track partner-specific differences separately when supplied.
06Acceptance and release readiness29 Mar–23 Apr 2027Target 23 Apr 2027
An API and connector release candidate passes OpenIRIS acceptance and is ready to deploy.
What we will deliver
- Run OpenIRIS QA acceptance against the documented baseline and resolve release-blocking defects.
- Complete real-SQL booking parity checks and end-to-end checks against our private eLabFTW instance, including permissions, pricing, time zones, revocation and performance.
- Rehearse release, rollback and connector recovery; finish monitoring, support, test-instance maintenance and handover.
- If Charité provides connection details, perform a focused compatibility/configuration check; record any local deployment restrictions without holding up the general release.
07Production delivery and handover26 Apr–7 May 2027Target 7 May 2027
The Public API and a tested, documented connector package are released and handed over.
What we will deliver
- Release the accepted Public API and verify it in production; deliver the connector package validated on our own eLabFTW instance.
- Provide API documentation, installation/configuration examples, key-management instructions and support contacts.
- Hand over connector operation and the private test instance, including secure credential transfer, reset, backup, upgrades and recovery instructions.
- Activate the connection to Charité’s installation when its endpoint, API credentials and authorised mappings are available; retain launch contingency through 7 May.
How we keep delivery on track
Quality from the first release
Our QA team validates every increment on our own environments. API parity tests check existing OpenIRIS behaviour; end-to-end tests prove the connector works with eLabFTW. April focuses on acceptance and fixes.
Regular, visible progress
Fortnightly demonstrations and monthly milestone reviews make progress tangible. New requirements are prioritised against the agreed scope and delivery window.
Independent integration testing
We supply the private eLabFTW instance and qualify the connector ourselves. Charité can review a prepared demonstration and provide installation details when ready; their availability does not gate development.
Minimal input from Charité.
We can build and accept the integration on our own setup. Connecting to their installation needs only a focused handover.
- Version and any local restrictions
Useful when available: their eLabFTW version and relevant access or customisation constraints. We start on a selected supported release and document compatibility assumptions.
- Connection details at deployment
Their administrator configures the installation URL, scoped API credentials and authorised user/resource mappings using our guide, plus any local network access. Credentials and production data do not need to be sent to us.
- A short workflow check
We provide a prepared demonstration and setup guide. A brief walkthrough can confirm local fit; it does not gate development, automated QA or delivery of the general connector.