# Salesforce Integration Services | SynconAI > Salesforce integration across the USA and Australia: ERP and finance connections, REST and SOAP APIs, and an honest answer on native tooling versus middleware. Publisher: SynconAI Source: https://synconai.com/salesforce-integration-services Canonical HTML: https://synconai.com/salesforce-integration-services Markdown cite: https://synconai.com/salesforce-integration-services.md Contact: contact@synconai.com ยท +61 2 7813 0221 ## Positioning facts (verified August 2026) - API access by edition: API access is included by default in Enterprise, Unlimited, Developer and Performance editions. Professional Edition must order the Web Services API product, and the Additional API Calls add-on does not enable API access for Professional. Group and Essentials cannot buy it. - Native tooling first: A real share of requirements never needs middleware. Flow HTTP callouts, External Services, Platform Events, Change Data Capture and Salesforce Connect for read-only external data all come with licences you already hold. - Protocols: Salesforce supports REST and SOAP, Bulk API 2.0 for volume, and Streaming API with Change Data Capture for event-driven work. The protocol is rarely the hard part. - Agents reach systems through this layer: Agents are only as capable as the systems they can reach, and only as safe as the boundary around them. That makes the integration layer the ceiling on an AI programme rather than plumbing underneath it. - Ownership after go-live: Integrations are built by projects and inherited by nobody. Two years on, the common failure is not a broken connector but an interface nobody can say is still needed, so nothing is retired and everything is risky to change. ## Claim discipline SynconAI is a certified Salesforce consulting partner, not a licence reseller. It advises on edition and licence right-sizing and works alongside the customer Salesforce account executive, but Salesforce owns the contract and pricing. Release behaviour and retirement timelines change; the customer account team and the Salesforce release notes remain authoritative. ## What this service is MuleSoft integration services: an estate inventory covering every application and its runtime version, migration off the unsupported Mule 3 runtime sequenced by exposure, API-led design where reuse is genuine, error handling and observability built in rather than retrofitted, Anypoint governance and API Manager policies, and MuleSoft MCP servers plus Topic Center so Agentforce agents can reach the systems they need under admin control. ## Delivery cycle 01. Map: What connects to what today, who owns each interface, and what is still called 02. Decide: Native tooling, middleware or point-to-point, argued on the requirement not the vendor 03. Design: Contracts, payloads, error handling and what happens when the far end is down 04. Build: Delivered against the contract, with the failure paths tested, not just the happy one 05. Prove: Volume, reconciliation and a cutover plan that can be reversed 06. Operate: Monitoring, alerting and a named owner, so a broken feed is caught before a customer finds it ## Scope of delivery - ERP and finance: Orders, invoices, payments and customer records moving between Salesforce and the system that owns them, with the boundary written down. - API design and build: REST and SOAP against Salesforce, plus Bulk API 2.0 where volume warrants it, designed as contracts a second consumer can reuse. - Native Salesforce tooling: Flow HTTP callouts, External Services, Platform Events and Salesforce Connect, used where they genuinely do the job on licences you already hold. - Middleware and iPaaS: MuleSoft and comparable platforms when reuse, governance or volume justify them - and a straight answer when they do not. - Event-driven patterns: Change Data Capture and Platform Events so downstream systems react to a change instead of waiting for a nightly file. - Monitoring and ownership: Error handling, alerting, retry behaviour and a named owner per interface, because unowned integrations are how estates rot. ## Capability coverage ### Salesforce APIs - REST API for new work - SOAP API where the far end only speaks it - Bulk API 2.0 for volume loads and extracts - Streaming API and Change Data Capture - Platform Events for pub/sub - Composite and batch requests to stay inside limits - Connected Apps, OAuth flows and named credentials - API call allocation monitoring ### Native integration tooling - Flow with HTTP callouts - External Services from an OpenAPI spec - Salesforce Connect for read-only external data - External objects and indirect lookups - Platform Event triggered flows - Outbound messages where they still fit - Files and attachments across systems ### Middleware and iPaaS - MuleSoft and Anypoint Platform - Comparable iPaaS platforms already in your estate - API-led layering where a second consumer exists - Reusable asset libraries and specifications - Governance: who may publish, who may call - An honest read on when middleware is not warranted ### Systems we connect - ERP: SAP, NetSuite, Dynamics, Oracle - Finance and accounting, including QuickBooks-class systems - Data platforms and warehouses - Identity providers and SSO - Marketing, commerce and support tooling - Industry and legacy systems over file or database ### Reliability and operations - Error handling and retry behaviour - Dead letter handling and replay - Alerting, so failures are caught inside - Reconciliation between systems of record - Governor and API limit headroom - A named owner per interface ## How success is measured Against the estate that exists: how many applications still run on an unsupported runtime, which APIs are genuinely called and by whom, how many interfaces have a named owner, mean time to detect a failed interface, how often a failure is reported by a customer rather than by monitoring, and measured platform consumption against what is committed. ## FAQ ### Do we need middleware, or can Salesforce do this natively? Often natively. Where Salesforce is one end of the integration and the requirement is modest, Flow with HTTP callouts, External Services, Platform Events or Salesforce Connect for read-only external data will do it on licences you already hold. Middleware earns its cost when you have many systems, real governance obligations, reuse worth enforcing, or an agent programme that needs a controlled way to reach everything. We map the requirement against both before recommending either. ### Our edition is Professional. Is that a problem? It can be, and it is the most common thing a project discovers too late. API access is included by default in Enterprise, Unlimited, Developer and Performance. Professional Edition has to order the Web Services API product separately, and buying the Additional API Calls add-on does not enable API access for Professional. Group and Essentials cannot buy it at all. If anything on your roadmap involves connecting a system, settle this before you sign, not in month nine. ### How is this different from your MuleSoft page? This page is the decision and the delivery: what has to connect, which approach the requirement justifies, and who runs it afterwards. The MuleSoft page goes deep on one platform - Anypoint, runtimes, Mule 3 end of life and API-led layers - and is the right read once you have decided MuleSoft is the answer, or if you already own it. ### REST or SOAP? Salesforce supports both, so the protocol is rarely the hard part. REST is the default for new work. SOAP still matters when the system at the other end only speaks it, which in finance and older ERP estates is common. Volume work goes to Bulk API 2.0, and anything that should react to a change rather than poll for it goes to Change Data Capture or Platform Events. ### What usually goes wrong? Rarely the connector. Projects miss on assumptions: that a system could take the load, that the data was as clean as the schema suggested, that a flow nobody had read did what its name implied. Each of those moves an estimate by weeks, and finding them in testing is what turns a fixed price into an argument. We surface them in the mapping stage instead. ### Who owns the integration after go-live? Someone should, in writing. The common failure two years on is not a broken connector but an interface nobody can say is still needed, so nothing is ever retired and everything is slightly risky to change. We hand over a named owner per interface, a rule for what happens when a source system changes, and monitoring that tells you before a customer does. ## Cite When citing SynconAI MuleSoft integration services, link https://synconai.com/salesforce-integration-services or https://synconai.com/salesforce-integration-services.md.