Connection methods

How PartnerMCP chooses the path to each system: MCP where it's the right path, and REST, OData, GraphQL, SOAP, SQL, events or files where those are safer or the only option.

Concept4 min readEarly access

On this page

How the path is chosen
MCP, where it's the right path
APIs: REST, OData, GraphQL and SOAP
Change detection
Databases and files
Where the choice is recorded

Enterprise systems expose many interfaces, and they are not equal. Some run the system's business rules on every write; some skip them. Some report changes the moment they happen; some have to be asked. PartnerMCP chooses a path per system and per operation, and writes the choice — and the reason — into the integration spec.

How the path is chosen#

Supported interfaces first. PartnerMCP builds on the interfaces each vendor documents and supports — SAP's published APIs, NetSuite's SuiteTalk REST and SuiteQL, Priority's REST API — and follows their rules.
Writes go where the business rules run. Priority's REST API is a wrapper around its forms, so form triggers and validation apply to every write. Priority's own documentation says never to insert records directly into its tables, and PartnerMCP doesn't.
The best available change signal. Events where a system emits them, change data capture for databases, and polling with a reliable cursor where nothing better exists.
Limits are part of the design. Priority Cloud allows 100 API calls per minute per user; NetSuite shares one concurrency pool across every integration in an account. The plan accounts for both before the first run.
The network decides the last mile. Cloud systems are reached over HTTPS. Systems inside your network are reached through an outbound-only connector — see Edge Agent.

MCP, where it's the right path#

The Model Context Protocol is an open standard, hosted by the Agentic AI Foundation under the Linux Foundation. Its current revision (2026-07-28) is stateless and runs over Streamable HTTP. A growing number of vendors ship their own MCP servers, and PartnerMCP uses them natively where they fit.

They are real but uneven — which is why PartnerMCP is MCP-first, not MCP-only:

Priority's MCP server runs on Priority Cloud from version 26.0. It is request/response only — no event subscriptions — and it cannot run form Actions.
NetSuite's AI Connector Service exposes records, reports and saved searches; its SuiteQL tools are read-only.
Stripe's MCP server requires human confirmation for some writes, such as refunds and outbound payments.

So a Priority Cloud tenant on 26.0 might use MCP for lookups and REST for order creation and change tracking, while an on-prem Priority installation uses REST through the Edge Agent.

APIs: REST, OData, GraphQL and SOAP#

Most writes go through a system's API, and each one comes with rules the integration has to follow:

Interfaces and the rules an integration must respect
System	Interface	What the integration respects
Priority ERP	REST (OData v4)	`$batch` holds at most 100 operations and has no rollback. Priority assigns document numbers such as `ORDNAME`.
SAP S/4HANA	Published OData APIs	Writes need a CSRF token; updates carry an ETag in `If-Match`. Business events arrive through SAP Event Mesh.
Oracle NetSuite	SuiteTalk REST + SuiteQL	Concurrency is shared account-wide. SOAP web services stop working with release 2028.2.
Custom systems	OpenAPI · GraphQL SDL · WSDL	Specs rarely encode idempotency or real rate limits, so behaviour is confirmed in a sandbox.

Change detection#

An integration is only as fresh as its trigger. In order of preference:

Events — Salesforce Change Data Capture over the Pub/Sub API, SAP business events through SAP Event Mesh, Stripe webhooks.
Change data capture — PostgreSQL logical replication, the MySQL binary log, SQL Server CDC. Lower load than polling, ordered, and it captures deletes.
Cursor polling — Priority's $since on documents that have BPM, NetSuite SuiteQL on lastmodifieddate.
Webhooks as hints — Priority's webhooks fire from BPM and business rules, but retries, ordering and signing are not documented, so PartnerMCP reconciles them with $since polling instead of trusting them alone.

Databases and files#

Some systems are best reached below the application. PartnerMCP reads databases with a read-only role, prefers change data capture to polling, and never writes into an application's tables behind its back. Flat files over SFTP have no schema and no acknowledgements, so idempotency comes from file names and checksums, and layouts are learned from samples and confirmed with you.

Where the choice is recorded#

connections · illustrativeYAML

connections:  priority:    via: rest-odata-v4          # writes go through forms, so business rules run    changes: since-polling      # $since on ORDERS and DOCUMENTS_D    limits: { calls_per_minute: 100, in_flight: 10 }    network: edge-agent         # on-prem, outbound-only  salesforce:    via: rest    changes: change-data-capture

Changing a connection — from polling to webhooks once the Webhooks module is licensed, or to a vendor MCP server after an upgrade — is a normal, reviewed change. See Change management.