Why Us

Why Synctrion

Interoperability complexity is a standards knowledge problem, not a connectivity problem.

Most integration products focus on moving information between systems. We focus on understanding the standards that define that information.

This page is for integration and enterprise architects who evaluate standards-governed exchange. It sets out the questions we believe decide that evaluation, and how Reactor answers each one today.

In short: your integration platform moves documents. Reactor applies the standards knowledge those documents depend on.

Your integration platform already does its job

Reactor is not an integration platform or an ESB. Integration platforms, ESBs and iPaaS own connectivity, routing, orchestration, transport and protocol management. Keep them.

Reactor owns a different responsibility: validation, transformation and version migration of standards-based documents. The knowledge those operations need sits in one standards knowledge layer, not inside each integration.

Keep the platform you have. Reactor works beside it, not instead of it.

Standards Intelligence organizes and governs standards knowledge. Reactor operationalizes that knowledge. OAGi governs OAGIS/connectSpec. Synctrion governs its own knowledge of the standard and how Reactor applies it.

For approvers: keep the platform you have. Reactor works beside it, not instead of it.

Five questions decide standards-governed exchange

Ask these of any approach you evaluate, including ours.

The question	Why it matters	Reactor today
Where does version knowledge live?	When it lives in each integration, you pay for it again at every version change.	Reactor's version migration logic is generated from the standard's own definitions. It is not hand-written for each pair of versions. The closed beta supports OAGIS 9.0 through 10.6.
What happens to data that has no place in the target version?	Dropped data is found in production, not in review.	When a document moves between OAGIS releases, content that has no place in the target release is kept in a marked standard extension, together with the release it came from. Planned: restoring that content when the document returns to its original release.
What survives a change of syntax?	JSON has no native place for XML namespaces. A round trip must restore them.	Reactor transforms OAGIS documents between XML and JSON, and restores XML namespaces on the way back.
Does validation mean the same thing in XML and JSON?	By default, JSON Schema treats the date-time format as an annotation. XSD enforces it. The same timestamp can pass one and fail the other.	Reactor validates dates, times and durations against the rules each representation declares: XSD types in XML, RFC 3339 in JSON. As an option, it also applies the ISO 8601 rules that OAGIS documents but its schemas do not enforce.
Are errors machine-readable and standards-based?	Partners settle disputes from the error response, not from your logs.	Errors are returned as RFC 9457 Problem Details, in XML or JSON. MessagePack responses carry the same members as the JSON form.

For approvers: these five questions are the checklist. Put them to every vendor on the shortlist.

Why this does not belong in your integration platform

Every standards-based landscape pays a hidden version tax. The work multiplies: standards × versions × syntaxes × systems × participants. Each factor adds mappings, rules and specialist knowledge to each integration.

An integration platform can host that logic. It still has to be written again for each integration, because the platform's job is the message path, not the standard.

The result is a false choice. Freeze on an old version and carry the risk. Or force an upgrade through systems that already work. We believe a version change should be handled once, where the standards knowledge lives.

For approvers: the cost is not the first integration. It is every version change after it.

What Reactor changes, and what it leaves alone

Reactor takes over the version-specific migration logic and standards knowledge that today sit inside your integrations. Your integration platforms, ESBs and applications stay in place.

We recommend starting with one document flow and one version pair. Extend to more flows, partners and versions from there.

Where Reactor stands today

Reactor is in closed beta with selected participants. It is not yet open to external organizations.
The closed beta supports XML, JSON, and MessagePack.
Validate, Transform and Migrate are available over a REST API.
In September 2025, Synctrion presented the first beta demonstration of Reactor to OAGi.
Planned: a broader beta program, with the subscription pricing model announced alongside it.

Supported versions, syntaxes and deployment options are detailed in Questions and Answers.

Request beta access

Tell us which standards, versions and syntaxes you run. We usually reply within 1-2 business days.