Yes. Any customized Salesforce org can be integrated with your product or with a development partner's code, because custom objects and custom fields are exposed through the same APIs as standard ones. The hard part is not access. It is that every customer's org is customized differently, and your integration has to discover those differences, respect the org's shared API allocation, and keep working after the customer's admin changes something.
That makes this a product decision for a SaaS company, not a one-off project. Enterprise buyers expect your product to read and write their own fields, and whoever builds the integration also inherits years of maintenance across many orgs. Appnigma's done-for-you integrations team is one way to hand that work off ("Build your product. We'll build the integrations."), with a named integration engineer and ongoing maintenance. Its page puts the per-customer problem plainly, "Standard objects for one account. Custom objects and field mappings for another." If you are an internal Salesforce team connecting your own systems, our guide to Salesforce integration patterns is the better fit.
Updated October 2026. Checked against Salesforce's REST API Developer Guide, the Salesforce Developer Limits and Allocations Quick Reference, the Platform Events and Named Credentials guides, and the Integration Patterns and Practices guide. The earlier version of this post overstated the daily API allocation and the Bulk API record limit, recommended Process Builder, and told stories about unnamed customers we can't source. This version replaces them with documented limits, a worked API budget, and the per-customer problems a SaaS integration has to solve.
What a customized org changes for your integration
A customized org is one where the admin has added objects, fields, rules and automation on top of the standard data model. Custom objects and custom fields carry the __c suffix, and the Salesforce CLI reference says custom object names "always end in" that suffix (schema generate field). Your product can read and write them, but only after it knows they exist, and the names differ in every customer org.
Four differences cause most of the work.
The first is the schema itself. Customer A tracks contract value in Contract_Value__c on Opportunity, customer B in ARR__c, and customer C on a custom Subscription__c object. Hardcoding any one of them breaks the other two.
The second is visibility. The REST API only returns fields the integration user can see. "Fields that are inaccessible to you by field-level security are not returned in the response body," per Get Field Values from a Standard Object Record. A missing field in your response usually means a permission gap in that customer's org, not a bug in your code.
The third is the rules the admin added. Validation rules and required fields apply to records your integration writes, and a rejected write comes back with an error such as FIELD_CUSTOM_VALIDATION_EXCEPTION, listed in the API status codes. The rule's own message tells you what the customer expects, so surface it to them instead of retrying.
The fourth is the edition. Enterprise, Unlimited and Developer Edition orgs have API access, as do Performance orgs. Professional Edition needs an add-on, per Supported Editions. A prospect on Professional Edition without it will see API_DISABLED_FOR_ORG, so ask about the edition during the sales cycle, not at install.
How your product discovers each customer's custom fields
The pattern that holds up across many orgs is discover, map, then sync. Your product asks the org what it contains, the customer's admin maps their fields to yours once, and the sync uses the stored mapping.
Discovery uses the describe resources. Describe Global "returns both custom and standard objects," and a per-object describe returns each field's API name, type, and whether it is required or updateable.
GET /services/data/v68.0/sobjects/Opportunity/describe
Authorization: Bearer <access token>
If-Modified-Since: Mon, 26 Oct 2026 00:00:00 GMTThe If-Modified-Since header makes the call cheap to repeat. If the object's metadata hasn't changed since that date, Salesforce answers 304 Not Modified, so you can re-check each customer's schema daily and only rebuild the mapping screen when an admin actually changed something.
Store the mapping per customer org in your product, keyed by field API name, and let the customer's admin edit it in your UI. Ship sensible defaults for the standard objects, then layer each customer's custom fields on top, so a change for one customer never changes the integration for the others. That one screen replaces most of the custom code a services firm would otherwise write per client.
For writes, match records with an External ID field rather than storing Salesforce record IDs on your side. An upsert on an external ID creates the record if no match exists and updates it if one does, per Upsert a Record Using an External ID. Ask each customer to create one external ID field (for example Your_Product_Id__c) during setup. If the value matches more than one record, Salesforce returns a 300 error and "no records are created or updated," which is your signal to flag duplicates for the customer rather than guess.
What one sync costs the customer's daily API allocation
Your integration spends the customer's API allocation, not yours. For Enterprise Edition the daily allocation is 100,000 calls plus 1,000 per Salesforce license and any purchased add-ons (API request limits). The same page notes that "API calls made from installed managed packages, count against your org limit," so every tool the customer has installed draws from one pool.
Here is the arithmetic for a hypothetical Enterprise Edition customer with 50 Salesforce licenses, using only the documented limits.
| Approach | Calls per day | Share of 150,000 |
|---|---|---|
| Daily allocation (100,000 + 50 x 1,000) | 150,000 | 100% |
| 20,000 changed records, one PATCH per record | 20,000 | 13.3% |
| Same 20,000 records via sObject Collections upsert, 200 per request | 100 | 0.07% |
| Polling 3 objects every 5 minutes, even when nothing changed | 864 | 0.6% |
The middle rows are why batching matters. An sObject Collections request can upsert "up to 200 records based on an external ID field" (sObject Collections upsert), and "the entire request counts as a single call toward your API limits" (sObject Collections). Above a few thousand records, Bulk API 2.0 is the better tool. Salesforce advises that "jobs with fewer than 2,000 records should involve 'bulkified' synchronous calls in REST." Bulk uploads are capped at 150,000,000 records per rolling 24 hours across the org (Bulk API limits).
Polling looks small in the table, but it scales with every object and every customer you add, and it misses changes between polls. Change Data Capture avoids both. "Change events are available for all custom objects and a subset of standard objects" (CDC objects), and Salesforce recommends the Pub/Sub API for subscribing (Streaming API overview). Event deliveries have their own allocation, 25,000 per 24 hours for Enterprise Edition, per Default Platform Event Allocations. Our post on Platform Events vs Change Data Capture covers the choice in detail.
Two delivery details shape your code. Events are kept for 72 hours and delivered in order (event bus architecture), but for fire-and-forget calls "there is no retry on the Salesforce side" (Fire and Forget pattern). Store the last replay ID per customer and make every write idempotent, so a replay after downtime never creates duplicates.
Build it in-house, hire a development partner, or ship a packaged app?
Three routes work, and the right one depends on how many customer orgs you will connect and how much custom logic has to run inside Salesforce.
| Route | Fits when | What you own afterwards |
|---|---|---|
| API integration built by your engineers | Logic lives in your product, a few object types, a team that knows Salesforce APIs | Every customer's auth, mapping and errors, forever |
| Development partner builds and maintains it | Integrations are a sales requirement but not your core product | A contract, and code you should keep in your repository |
| Managed package installed in each customer org | Logic, UI or automation must run inside Salesforce | Versions, upgrades and a security review for AppExchange |
The API route keeps everything in your stack. Your product authenticates to each org through OAuth, and for new integrations Salesforce now points you to External Client Apps because "connected apps creation is restricted as of Spring '26" (Create a Connected App). See our guide to creating an External Client App for the setup. Ask customers to run the integration as a dedicated user on the Salesforce Integration user license, which grants "full org access while limiting them to API-only operations" (Supported Editions). Our integration user guide explains the license and permissions.
The packaged route puts code inside each customer's org. A managed package can ship the named credential, the external credential and a permission set, but "access tokens aren't packageable," so each customer enters their own credentials after install (Package Credentials). Use the current model, since legacy named credentials "are deprecated and will be discontinued in a future release" (Named Credentials). Package code also can't reach a customer's own custom objects by default. Dynamic Apex can only access the components it was packaged with until the customer's admin grants more (package security). Our managed package guide and Named Credentials post go deeper.
A common setup is a mix of the first and third routes. The sync runs over the API from their product, and a small package adds a Lightning component or Flow action when customers want the data on the record page. Appnigma's integration infrastructure is for teams whose own engineers build the integration. That page describes the same layering, "Start with default mappings," then add custom objects and field transformations for individual customers. The marketplace apps offering covers the packaged route, with "a native app, marketplace listing preparation, and review support."
Mistakes that break integrations with customized orgs
These show up after the second or third customer, when the integration meets an org it wasn't tested against.
- Hardcoded field names. The first customer's
ARR__cends up in code, and the next customer's org fails on install. Keep every custom field name in the per-customer mapping. - Testing in an empty developer org. A clean org has no validation rules, record types or required custom fields. Test against a sandbox copy of a real customer org before each new customer goes live.
- An integration user without field access. Fields hidden by field-level security are silently left out of responses, so the sync "works" with blank values. Check field access during setup and show the customer what is missing.
- Retrying validation errors. A
FIELD_CUSTOM_VALIDATION_EXCEPTIONwill fail on every retry. Route it to the customer with the rule's message. - Polling every object. It burns API calls in every org whether data changed or not. Subscribe to change events where the edition allows it.
- Building new automation on Process Builder. Support for Workflow Rules and Process Builder ended on December 31, 2025, and new processes can't be created (Salesforce Help). Use Flow.
- No per-customer monitoring. One customer's expired token or full API allocation looks like a healthy integration in aggregate. Track errors and last successful sync per org.
Frequently Asked Questions
Can you integrate a custom Salesforce CRM with development services?
Yes. Custom objects and fields are available through the same REST, Bulk and event APIs as standard ones. The work is discovering each org's customizations, mapping them, and staying within that org's shared daily API allocation.
How many API calls does a Salesforce org get per day?
Enterprise Edition gets 100,000 plus 1,000 per Salesforce license per rolling 24 hours. A 15-license org gets 115,000 (API request limits). Installed packages and every other integration share that number.
How do I sync custom Salesforce objects with my SaaS app?
Use a describe call to list the customer's objects and fields, let their admin map fields in your product, upsert on an External ID field in batches of up to 200, and subscribe to Change Data Capture instead of polling.
Should we build the integration in-house or hire a Salesforce development partner?
Build in-house if Salesforce is core to your product and your team will maintain it. Use a partner when integrations are a sales requirement but not your product, and keep the code in your own repository either way. Our build in-house vs Appnigma comparison walks through the trade-off.
Can Appnigma build our Salesforce integration?
Yes. Appnigma's done-for-you team builds and maintains customer-facing integrations with a named integration engineer, and its marketplace apps team builds native Salesforce apps when the integration needs to run inside the customer's org.
About the author. Sunny Chauhan is the co-founder and CEO of Appnigma AI, which builds and maintains customer integrations and native Salesforce and HubSpot apps for B2B SaaS teams. Before Appnigma, he was on Salesforce's AppExchange team, where he worked with more than 300 SaaS partners. He has spent close to a decade on the Salesforce platform, including work at Zennify, and holds Salesforce certifications including Platform Developer II, Platform App Builder, Administrator, Data Cloud Consultant, and AI Associate.
Related Articles
- Salesforce integration patterns and best practices
- How each integration route handles customer custom objects
- Which kind of Salesforce partner a SaaS company needs
- Platform Events vs Change Data Capture
- Salesforce Bulk API 2.0 guide
- Salesforce integration user license and setup
Sources
- API Request Limits and Allocations, Salesforce Developer Limits Quick Reference
- Bulk API and Bulk API 2.0 Limits
- Supported Editions, REST API Developer Guide
- Describe Global, REST API Developer Guide
- Get Field Values from a Standard Object Record, REST API Developer Guide
- Upsert a Record Using an External ID, REST API Developer Guide
- Upsert Records Using sObject Collections, REST API Developer Guide
- Core Data Types Used in API Calls (status codes)
- Default Platform Event Allocations
- Platform Event Architecture
- Remote Process Invocation, Fire and Forget, Integration Patterns and Practices
- Package Credentials, Named Credentials Developer Guide
- Create a Connected App, Mobile SDK Guide
- Workflow Rules and Process Builder end of support, Salesforce Help
