Reads a delta
Changed records since the last cursor, never a full corpus scan. Proven against a 12,000-record corpus with a 3-record delta: zero full scans.
Integrations
Eight connectors conformed. Nine declared. Cumulative, dated, rerunnable.
The counts are cumulative across every published build; each figure carries its date and its rerun command on the reconciliation page. Every connector below states what it was proven against, not what it is aimed at. Two were built from reviewed conformance specifications. Six were derived from public vendor documentation. Nine are scaffolds that report validated: false and cannot be promoted without a real tenant.
What "conformed" means here, precisely
Conformed means the adapter was executed against the published contract and passed every case. It does not mean it has run against a live instance of that vendor's system. No connector has. That distinction is the difference between a claim we can prove and one we cannot, so it is labelled on every row rather than in a footnote.
Reproduce this yourself: node tests/conformance/run-conformance.mjs at the release root. It runs every suite in that directory and prints the total. Today that is 34 suites and 823 cases, 0 failing, offline, no account, no vendor in the loop. If you run it and get a different number, this page is wrong and we want to know.
Conformed connectors
| System | Entity | Contract provenance | Cases | Status |
|---|---|---|---|---|
| SAP S/4HANA | PurchaseOrder | Reviewed conformance specification. OData v4, OAuth client credentials, LastChangeDateTime delta | 12/12 | Conformed |
| NetSuite | PurchaseOrder | Reviewed conformance specification. Self-identifies the account-timezone trap on lastmodifieddate | 12/12 | Conformed |
| Oracle Fusion | PurchaseOrder | Derived from public REST documentation | 6/6 | Conformed |
| Microsoft Dynamics 365 F&O | PurchaseOrder | Derived from public OData documentation | 6/6 | Conformed |
| Coupa | PurchaseOrder | Derived from public Core API documentation | 6/6 | Conformed |
| Infor CloudSuite | PurchaseOrder | Derived from public ION/M3 documentation | 6/6 | Conformed |
| Workday | Worker (HCM) | Derived from public RaaS/REST documentation | 8/8 | Conformed |
| Generic REST | PurchaseOrder | Configuration-driven. You supply the field map | 6/6 | Conformed |
Source: src/adapters/, tests/conformance/. The adapter-specific subset is included in the 34/823 total above rather than counted separately, so the number on this page and the number the command prints are always the same number.
Declared scaffolds
Nine further systems have adapter scaffolds carrying 117 conformance cases at mock maturity. They are not conformed and the suite enforces that. After a successful fetch, each must still report validated: false; forcing it true fails nine cases immediately.
| System | Cases | Status |
|---|---|---|
| SAP Ariba | 13 | Scaffold declared |
| SAP ECC | 13 | Scaffold declared |
| Jaggaer | 13 | Scaffold declared |
| Ivalua | 13 | Scaffold declared |
| Anaplan | 13 | Scaffold declared |
| o9 Solutions | 13 | Scaffold declared |
| DocuSign CLM | 13 | Scaffold declared |
| Ironclad | 13 | Scaffold declared |
| Salesforce | 13 | Scaffold declared |
Why a scaffold cannot be promoted from here
Passing against a faithful mock proves an adapter conforms to a specification derived from public documentation. It does not prove the vendor's real API matches that reading. Endpoint paths, field names, status enumerations and pagination shapes are customer-configurable and version-dependent. Ariba realms, ECC release levels, Salesforce custom objects and Ivalua configurations all vary per deployment. Promotion requires tenant access or a customer-confirmed field mapping, a written conformance specification, a run against the real system, and a signed tenant-confirmation artifact. Until all four exist, the honest label is the one above.
What every connector does, and never does
Maps to canonical
Source fields to the canonical object, with the source, timestamp and record reference retained so the trace reconstructs later.
Never writes
There is no write method to disable. The write-path suite passes 9/9 because no write call exists to fail with.
Preserves disagreement
When two systems report different values for one object at the same timestamp, the connector surfaces the conflict rather than picking a winner.
Isolates bad rows
A malformed source row is skipped and reported, never fatal. Cursor never advances past an unpersisted record.
Recovers auth mid-sync
A mid-sync 401 invalidates the cached token, re-authenticates and rebuilds the request rather than exhausting retries.
What you provide
| Item | Detail |
|---|---|
| Credentials | Read-only service account per system. OAuth client credentials where the vendor supports it, API key where it does not. Held in a secrets vault, never in configuration. |
| Scope | One entity to begin, typically PurchaseOrder. A slice, not the estate. |
| Network | Outbound reachability from the EOS deployment to your systems. Air-gapped deployment is supported; the trade is manual delta transfer. |
| Time | Thirty minutes to scope. An afternoon to deploy against a read-only slice. |
Your stack is not on this list
The Generic REST connector is configuration-driven and takes a field map you supply. Where the source is honestly still a spreadsheet, there is a spreadsheet path, because most estates have one and pretending otherwise wastes the first meeting.
Tell us the two systems that disagree and we will say plainly whether a connector exists, whether a scaffold can be promoted, or whether it is new work.