A practical guide to connecting Salesforce from a Spring Boot application: which API to pick, how to authenticate without a browser, and the failure modes worth handling before they reach production.
The REST API covers most CRUD and query work. Bulk API 2.0 is for volume — tens of thousands of records and up — where per-record REST calls would exhaust your API limits. Streaming and Platform Events cover change notification rather than polling.
For an integration with no human present, the JWT Bearer flow is the right choice: a Connected App with an uploaded certificate, a pre-authorised user, and a signed assertion exchanged for an access token. No refresh tokens to rotate and no browser redirect.
Salesforce returns large result sets in pages with a nextRecordsUrl pointer; any query that can exceed the batch size needs to follow it. Select only the fields you need — wide queries cost more and hit limits sooner.
Insert, update and delete are straightforward. Upsert against an external ID field is the pattern that matters for synchronisation, because it makes the operation idempotent — a retried call updates rather than duplicating.
Plan for API limit exhaustion, row-level lock contention on parallel writes, validation rules rejecting records the integration considers valid, and expired or revoked tokens. These need distinct handling: some are retryable with backoff, others must surface to a human.
FlowSetu generates this as a Spring Boot project with a Salesforce connector — authentication, pagination, and retry included — which you own and run yourself. See the connector overview.