Coverage and limits
What the engine supports — by protocol, auth pattern and system — and where the boundaries sit.
Protocols
| Protocol | Status |
|---|---|
| REST / JSON | Supported |
| SOAP | Supported |
| GraphQL | Supported |
| Webhooks | Supported |
| EDI | Supported |
| MCP (agent-to-tool) | Supported |
| A2A (agent-to-agent) | Supported |
What makes a source harder
The engine reads a system to build against it, so how much it can infer depends on how much that system tells it. These are the cases where it asks more questions and answers fewer on its own — listed here rather than discovered at first run.
- Undocumented APIs. The engine infers from what it can read; with nothing to read, it infers less and asks more.
- Non-semantic field names. A source whose fields are
f1,f2,f3gives the engine nothing to reason about, and the mappings arrive as questions rather than answers. - Unusual pagination. Cursor schemes that do not follow a common shape need a person to describe them once.
- Stale documentation. Docs that disagree with the live API produce confident mappings that are confidently wrong — this is the case the confidence line is least able to catch.
- SOAP and EDI implementation variance. Both are supported, and both vary enormously by implementation — a well-formed one is straightforward, a bespoke one takes longer.
What this means for a new connector
The platform builds connectors autonomously — it discovers the API, maps what it is confident about, and asks about the rest. Source quality changes the ratio, not the process.
A documented, sensibly-named source produces something close to a catalog connector with no involvement from you. A poorly documented one produces a connector with fields the engine could not name confidently, and it surfaces those for someone to confirm rather than guessing at them.
That is the confidence line doing its job: the engine tells you what it is unsure about instead of quietly getting it wrong.