July 11, 2026
We built a working Salesforce API integration in three hours - connecting a third-party field-service system to Salesforce so work-order updates flowed in near real time. The speed didn't come from cutting corners; it came from a reusable pattern: REST API over Named Credentials, a dedicated integration user, and error handling we'd built once and kept. This is the exact play, hour by hour, so you can run it too.
Here's how the three hours broke down:
Written by the Minuscule Technologies Salesforce engineering team. Client details anonymized under NDA. Last reviewed July 2026.
Our team has built Salesforce integrations since 2014, with 160+ Salesforce specialists and certified architects who've delivered 75+ projects for enterprises, including Nasdaq-listed firms. Integrations - the messy, auth-heavy, governor-limit kind - are a large part of what we do, so the walkthrough below comes from production work, not theory.
A field-service company was running its dispatch and job tracking in a third-party operations platform, while sales and account management lived in Salesforce. The two never talked. When a technician closed a job in the ops platform, the account team in Salesforce had no idea until someone emailed them - usually a day late.
The ask was narrow and clear: when a work order updates in the external system, push that status and a few key fields into the matching Salesforce record within minutes. No full data warehouse, no massive migration - just a clean, reliable Salesforce API integration for one high-value data flow. A tight scope is the first reason three hours was realistic.
A Salesforce API integration is a connection that lets an external system read from or write to Salesforce programmatically through its APIs, instead of anyone entering data by hand. Salesforce exposes several APIs for this - the Salesforce REST API, SOAP API, Bulk API, and Streaming API - and you pick based on data volume, timing, and the calling system. It's the backbone of Salesforce CRM integration: the way your CRM shares data with the tools around it.
In practice, most modern integrations use the REST API: it's lightweight, speaks JSON, and works well for record-level reads and writes triggered by events. That's what we used here, calling into Salesforce from the external platform and, for outbound updates, making Apex callouts from Salesforce to the third-party service.
Two ideas shape every Salesforce API integration. Timing is either synchronous (you call and wait for the response) or asynchronous (you fire the call and keep working). Direction is either inbound (an external system calls Salesforce) or outbound (Salesforce calls out to another system). Our build was mostly inbound and near real-time - the external platform called Salesforce the moment a work order changed, and Salesforce didn't sit and wait on it.
Salesforce still supports the Salesforce SOAP API, and it's a fine choice for legacy systems that already speak XML or need its strict typing. We chose the Salesforce REST API for three reasons: the external platform's developers were comfortable with JSON, we needed simple record-level operations rather than bulk loads, and REST callouts from Apex are quicker to stand up and test. For a heavy one-time load, we'd have reached for the Salesforce Bulk API instead.
Here's the quick decision guide we use on every project:
If this had been a one-time migration of hundreds of thousands of records rather than a live sync, we'd have used the Salesforce Bulk API. It's built for high volume - up to millions of records in a rolling 24-hour window - and processes them asynchronously in batches, which keeps you clear of the row-by-row limits a REST callout would hit.
It helps to place any Salesforce API integration in context before you build. Two quick frameworks cover most of it - the shape of the connection, and the pattern of data flow.
Most orgs use one of three shapes. Point-to-point connects two systems directly - simple, but it gets costly to maintain as connections multiply. Hub-and-spoke routes everything through a central hub, so each system connects once. Enterprise service bus (ESB) adds a messaging bus with routing, orchestration, transformation, and security for complex enterprises. Our single-flow build was point-to-point by design - one clean connection, not a platform.
Salesforce documents a handful of patterns worth knowing:
Authentication is where most Salesforce API integration projects lose their first day, so we front-load it. We set up a Connected App in Salesforce for OAuth 2.0, then created a dedicated integration user for the external system to authenticate as - never a person's login.
Rather than granting broad admin rights, we assigned the integration user a tight permission set: API Enabled, plus object and field permissions for only the records this flow touches (work orders and the related account fields). That's the "salesforce api integration permission set" people search for - a scoped bundle of permissions that gives the integration exactly what it needs and nothing more. It keeps the connection secure and makes every change traceable to that user.
On the Salesforce side, we stored the external service's credentials in Named Credentials so no secrets ever sat in code. Named Credentials handle the auth handshake and endpoint URL for you, which is both safer and faster than hand-rolling token management. Getting security right up front is the same discipline we bring to every Salesforce integration project.
Salesforce offers a free Salesforce Integration User license built for exactly this - an API-only user that can't log into the UI, with a small number included per org (five in most editions). It's the right home for an integration user because it keeps a full paid seat free while still granting API access. If you need more API-only users than the free allotment, additional Salesforce Integration licenses can be purchased. For this build, one free Salesforce Integration User covered the whole flow.
With auth done, the build moved fast. We kept the official Salesforce API documentation open for the REST endpoint and field details, then wrote a single Apex service class that made the REST callout to the external platform, parsed the JSON response, and mapped fields onto the Salesforce work-order record. Three decisions kept Hour 2 short.
Because the flow was event-driven, the external system called Salesforce whenever a work order changed, and our Apex handled inbound updates through the REST API. No polling, no scheduled jobs, no wasted API calls.
The last hour is where a rushed integration usually shows its cracks, so we spend it deliberately. We built the flow in a sandbox first, created test records that mirrored real work orders, and confirmed each one landed on the right Salesforce record with the right values.
Then we added the error handling that makes an integration trustworthy: every failed callout gets logged to a custom object with the payload and the error, so nothing fails silently. We also respected Salesforce governor limits - callout limits and timeouts especially - by keeping the operation lean and asynchronous where it mattered. Once the sandbox run was clean, we deployed to production through our CI/CD pipeline and watched the first live updates flow in. This kind of release discipline is core to our DevOps and automation practice.
The three hours came from reuse, not heroics. We weren't inventing an auth pattern, an error-logging object, or a callout structure on the spot - we'd built those before and kept them as accelerators. When the pattern is proven, the work becomes assembly, not invention.
Three things separated this from a project that drags for weeks:
None of this is unique to us - it's repeatable. But it does take a team that has run enough integrations to have the patterns ready, which is exactly what our managed services team keeps on hand.
Speed is only safe when you know where these projects usually break. Here are the traps we planned around before writing a line of code.
For the platform specifics behind these choices, the Salesforce Developer blog and Salesforce Admins resources are the primary references, and Apex Hours and Salesforce Ben cover the patterns in depth.
API integration in Salesforce is connecting an external system to Salesforce through its APIs so data moves programmatically instead of by hand. It lets another application create, read, update, or delete Salesforce records - for example, pushing order updates from an operations platform into Salesforce automatically.
Set up a Connected App for OAuth, create a dedicated integration user with an API-enabled permission set, store credentials in Named Credentials, then make REST (or SOAP) callouts that map external data to Salesforce fields. Build and test in a sandbox before deploying to production.
For real-time, system-to-system data flow, no - you need API access, which requires a Salesforce edition that includes it (Enterprise and above, or Professional with the API add-on). Manual imports and AppExchange tools exist, but a true programmatic integration depends on the API.
Use the REST API for most modern integrations - it's lightweight, uses JSON, and suits record-level, event-driven syncs. Choose SOAP for legacy systems that already speak XML or need strict typing, and use the Bulk API for large batch loads.
At minimum, API Enabled, plus object and field-level permissions for exactly the records the integration touches. Assign this scoped permission set to a dedicated integration user rather than granting broad admin access, so the connection stays secure and auditable.
A single, well-scoped data flow with a proven auth pattern can be built and tested in a few hours, as this one was. Broader integrations - many objects, custom transformations, or high volumes - take longer, but a tight scope and reusable patterns are what keep any build fast.
Salesforce publishes official API documentation on its developer site, with a separate developer guide for each API - the REST API, SOAP API, and Bulk API 2.0 guides. Start with the REST API Developer Guide for most modern integrations; it lists every endpoint, request format, and error code you'll map against.
You need a Salesforce edition with API access (Enterprise and above, or Professional with the API add-on), and the integration user should run on a Salesforce Integration User license - a free, API-only license with a small allotment included per org. It keeps a full paid seat open while still granting the API access the integration needs.
A three-hour Salesforce API integration isn't a magic trick - it's what happens when scope is tight, authentication is solved first, and the patterns are already proven. That's the difference a specialist team makes. At Minuscule Technologies, we handle Salesforce integrations, API development, and managed services for Nasdaq-listed enterprises, connecting Salesforce to ERPs, operations platforms, and data warehouses without the silos or the drawn-out timelines. If you've got a system that needs to talk to Salesforce, talk to our team about scoping it.
You've seen what's possible. Now, let's make it happen for your business. Whether you need an end-to-end Salesforce solution, a complex integration, or ongoing managed services, our team is ready to deliver.
Schedule a Free Strategic Call
