Last updated: October 2026 · Reviewed by ID-Pal
A native Salesforce integration runs identity verification inside the Salesforce org, against the record, with the vendor maintaining the package. An API bolt-on runs verification in the vendor’s system and relies on the firm’s own code to pass results back. For a regulated firm whose onboarding and case handling already live in Salesforce, native is usually the better choice, because the evidence stays on the record and there is no integration to maintain. ID-Pal offers both: a managed package on the Salesforce AgentExchange, and an API and SDK for firms building their own journey.
Key takeaways
The difference is where the evidence lives. Native keeps the full check on the Salesforce record. A bolt-on keeps it in another system and sends a summary back.
Native is maintained by the vendor. A managed package is updated through Salesforce releases by the vendor. An API build is the firm’s to maintain.
A bolt-on is not wrong. It suits firms with engineering capacity and a journey that runs outside Salesforce. It is the wrong default for a compliance team that lives in Salesforce.
You do not have to choose one vendor per route. ID-Pal supports both, so the decision can be made on the journey rather than on the supplier.
What is the difference between a native integration and an API bolt-on?
A native integration is a managed package installed into the Salesforce org from the AgentExchange. Verification is triggered from a lead, contact or account, the customer completes the check, and the result and report return to that record as Salesforce data. Configuration is done in Salesforce setup. The vendor maintains compatibility with each Salesforce release.
An API bolt-on is a connection the firm builds between Salesforce and a verification service. A flow or custom code calls the vendor’s API, the check runs in the vendor’s system, and the response is mapped back into Salesforce fields. The firm decides what comes back and where it goes, and owns the code that does it.
Both can verify a customer correctly. They differ in audit trail, upkeep, time to deploy and who carries the risk when something changes.
How do they compare on what a compliance team cares about?
| Native integration | API bolt-on | |
|---|---|---|
| Where the full check and report sit | On the Salesforce record | In the vendor’s system, with whatever the firm maps back |
| Trigger | From the record, by a user or a flow | From code or a flow the firm builds |
| Exceptions | Routed to a named reviewer in Salesforce | Wherever the firm’s build sends them |
| Time to deploy | Install and configure | Design, build, test, and release |
| Maintenance through Salesforce releases | Vendor | Firm |
| Customisation of the journey | Within the package’s configuration | Unlimited, at the firm’s cost |
| Best fit | Onboarding and case handling already in Salesforce | Journey runs outside Salesforce, or needs bespoke steps |
When is a native integration the right choice?
When the people doing onboarding, reviewing exceptions and answering auditors all work in Salesforce. Three signs point that way.
Case handling is in Salesforce. If a compliance analyst already works from Service Cloud or Financial Services Cloud, a check that lands anywhere else creates a second place to look.
Audit asks are answered from Salesforce. When a regulator or internal audit asks what was checked, when, by whom and with what result, the answer should be on the record, not reconstructed from two systems.
There is no engineering team to own an integration. A managed package is installed and configured. There is no code to review when Salesforce ships a release.
With ID-Pal’s native integration, a check started from the record covers document authentication across 16,000+ identity documents from 250+ jurisdictions, thousand-dimension biometric facial matching, liveness detection certified to iBeta Level 1 and Level 2, address e-verification and screening against sanctions, politically exposed persons and adverse media. The customer due diligence report attaches to the record. For business customers, entity confirmation and ultimate beneficial owner identification run through ID-Pal’s KYB capability, following the integration of NorthRow’s KYB platform.
When is an API bolt-on the right choice?
When the customer journey does not run through Salesforce, or needs steps a package cannot provide. Three cases.
The onboarding journey is in the firm’s own app or portal. If customers sign up through a product the firm built, verification belongs in that journey, with Salesforce receiving the outcome.
The firm needs bespoke logic. Unusual sequencing, custom risk scoring or integration with several downstream systems can justify owning the build.
Engineering capacity exists and is funded. An API build is a project with ongoing cost. Firms that have that capacity and want the control should use it.
ID-Pal’s API and SDK are the same verification engine as the native package, so a firm that starts on one route is not locked out of the other.
What goes wrong with each route?
Native, done badly: installing the package and leaving every setting on default, so a retail client and a corporate client get the same check. The fix is configuration. ID-Pal’s rule engine is fully configurable by customer type, product and risk.
Bolt-on, done badly: mapping only a pass or fail flag back into Salesforce and leaving the documents, the screening result and the reviewer’s decision in the vendor’s system. The firm then cannot answer an audit question from Salesforce. The fix is to bring the report back with the result, which is what the native route does by design.
Frequently asked questions
Is a native Salesforce integration more secure than an API connection?
Neither is inherently more secure. Both should run on a platform certified to ISO 27001, as ID-Pal’s is. The practical difference is that a native integration keeps the evidence in one system under Salesforce’s access controls, while a bolt-on spreads it across two systems the firm has to govern separately.
Can we start with the native integration and add API later?
Yes. ID-Pal’s native package and its API and SDK use the same verification engine, so a firm can run the managed package for Salesforce-based onboarding and the API for a separate customer app.
Does a native integration slow down onboarding?
No. Eligible journeys complete in minutes on the customer’s own phone, and the check can be triggered automatically from a flow at the stage the firm defines.
Who is responsible when Salesforce releases an update?
For a managed package, the vendor. ID-Pal maintains the AgentExchange package. For an API build, the firm’s own engineers.
What Salesforce products does the ID-Pal native integration need?
The listing requires Service Cloud, Experience Cloud or Financial Services Cloud, and is compatible with Sales Cloud.
Does the ID-Pal integration work with Agentforce?
Yes. The package does not depend on Agentforce, but once it is installed, Agentforce agents can work with ID-Pal data and actions like any other Salesforce data. If the firm’s Salesforce administrator sets up the workflow, an agent can start a customer verification and read the result on the record. There is no prebuilt agent workflow; the firm configures it.
Can a native integration handle corporate clients?
Yes. Entity confirmation and ultimate beneficial owner identification run through ID-Pal’s KYB capability, and the owners identified are verified and screened in the same pass, with the report attached to the account record.
