Ellipse Gradient for Header

nCino Integration Guide

nCino integrates with enterprise systems through Salesforce-based REST, bulk, asynchronous, SOAP, file, and event-driven interfaces.

nCino integration options at a glance

nCino implementations commonly operate within Salesforce and use Salesforce platform APIs together with nCino-specific objects and services. REST APIs are the primary option for transactional access, while Bulk API and asynchronous jobs support migrations, reconciliation, and high-volume synchronization. Salesforce SOAP APIs may support existing banking integrations, and Salesforce Files resources can handle documents through ContentVersion and related objects. Platform Events, Change Data Capture, outbound messages, Flow, or Apex can provide event-driven notifications for selected objects and events. Martini can consume these APIs, receive configured callbacks, schedule workflows, transform data, apply validation and business rules, and expose controlled APIs for downstream systems.

Integration pointSupported by nCino?Common use casesHow Martini supports it
REST APIsYesQuery, create, update, and delete accessible Salesforce and nCino data for transactional integrations. Access is governed by object permissions, sharing rules, field security, and package configuration.Martini can consume REST APIs, manage authenticated requests, follow pagination, transform payloads, and orchestrate multi-step workflows.
GraphQL APIsNot confirmedSalesforce provides GraphQL capabilities for selected platform use cases, but nCino-specific GraphQL coverage was not confirmed.Martini can consume GraphQL APIs where the required nCino data is confirmed to be exposed by the target Salesforce service; availability must be verified first.
SOAP APIsLimitedSalesforce Enterprise and Partner SOAP APIs can support existing banking or integration-layer dependencies, although they are generally not the preferred option for new work.Martini can consume SOAP services, apply XML mappings, and handle SOAP-specific authentication and errors when a project requires them.
Webhooks and outbound callbacksLimitedPlatform Events, Change Data Capture, outbound messages, Flow, Apex callouts, and custom callbacks can provide notifications for selected objects and events.Martini can expose APIs and receive webhook-style HTTP requests, validate event payloads, deduplicate notifications, and start downstream workflows.
Bulk and asynchronous APIsYesSalesforce Bulk API supports high-volume loading and extraction for migrations, periodic synchronization, reconciliation, and large Account, Contact, loan, or application datasets.Martini can submit and monitor asynchronous jobs, retrieve results, process partial failures, and persist checkpoints for restartable workflows.
File and attachment APIsYesSalesforce Files resources such as ContentVersion, ContentDocument, and ContentDocumentLink can support document metadata and file synchronization.Martini can coordinate file metadata and content transfers, associate files with target objects, and route large-file or external-document cases according to configured rules.
AuthenticationYesOAuth 2.0, JWT bearer flow, and other Salesforce-configured OAuth methods can authenticate connected applications and unattended integrations.Martini can store credentials and certificates securely, configure authenticated API consumption, and separate sandbox, production, and regional environment settings.
Database and analytics accessLimitedSalesforce reporting, analytics, data export, or warehouse processes may support analytical use cases, but direct access to an nCino production database is not the normal approach.Martini can consume supported reporting or API endpoints and load downstream databases, but it should not be described as connecting directly to nCino internal databases.

How nCino exposes data and business events

nCino REST APIs

Salesforce REST APIs are the primary standards-based interface for Salesforce-hosted nCino data. They can support queries and transactional operations on accessible objects, but exact nCino API names, fields, relationships, and permissions depend on the package and tenant configuration.

Martini implementation pattern

Martini implementation pattern: a workflow authenticates to the configured Salesforce environment, retrieves or submits REST resources, follows pagination, maps nCino and Salesforce payloads into a canonical model, and writes results to downstream systems with correlation and error handling.

Implementation sequence

Authenticate with the configured Salesforce OAuth or JWT flow
Retrieve the current Account, Contact, Loan Application, Loan, or related resource
Follow pagination or continuation links when more data is available
Map the payload to the canonical integration model
Apply validation, routing, and business rules
Write the transformed result to the target system and record the outcome

nCino Bulk and asynchronous APIs

Salesforce Bulk API and related asynchronous operations support high-volume extraction and loading for migrations, periodic synchronization, and reconciliation. Jobs and results are processed separately from individual REST requests, and batches can contain partial failures.

Martini implementation pattern

Martini implementation pattern: a workflow submits a bulk job, stores the job identifier, polls or retrieves completion results, processes successful and failed items independently, and persists checkpoints so an interrupted run can resume safely.

Implementation sequence

Create the bulk or asynchronous job with the approved object and operation
Store the job identifier and source watermark
Monitor job state without exceeding Salesforce limits
Retrieve result and failure details when processing completes
Map successful rows and route partial failures separately
Persist reconciliation results and the next synchronization checkpoint

nCino event notifications

Platform Events, Change Data Capture, outbound messages, Flow, Apex callouts, and custom callbacks can provide notifications for selected changes. Coverage is implementation-dependent and is not universal across nCino objects or business events.

Martini implementation pattern

Martini implementation pattern: Martini exposes an authenticated API or webhook workflow, validates the notification, records event or replay identifiers, retrieves the current resource when necessary, and distributes the change to downstream systems while tolerating duplicate delivery.

Implementation sequence

Receive the configured Salesforce or nCino callback
Authenticate the request and validate its event structure
Record the event, replay, or correlation identifier
Retrieve the current object when the notification is not a complete payload
Apply deduplication and business rules
Distribute the change and acknowledge or route failures appropriately

nCino SOAP APIs

Salesforce Enterprise and Partner SOAP APIs can support existing banking integrations and integration layers. REST and asynchronous APIs are generally more suitable for new implementations unless the nCino project specifically requires SOAP.

Martini implementation pattern

Martini implementation pattern: a workflow consumes the SOAP service, handles XML envelopes and namespaces, maps response and fault structures, and applies the same validation, correlation, retry, and monitoring controls used for other API integrations.

Implementation sequence

Configure the required SOAP endpoint and authentication
Submit the XML request for the required Salesforce operation
Parse the SOAP response or fault
Map the result to the canonical model
Apply validation and downstream business rules
Record the transaction and retry only recoverable failures

nCino Salesforce Files

Salesforce Files can be accessed through ContentVersion, ContentDocument, and ContentDocumentLink. The customer must confirm whether documents are stored in Salesforce, managed by nCino functionality, or held in an external document platform.

Martini implementation pattern

Martini implementation pattern: a workflow retrieves file metadata or content, maps document relationships, transfers content or references to the target platform, and preserves external identifiers, version information, and audit context.

Implementation sequence

Identify the source record and related Salesforce file objects
Retrieve file metadata and content using the configured API
Validate document type, size, security, and relationship information
Map metadata and associate the file with the target record
Transfer content or an approved external reference
Store the source version and target identifier for reconciliation

Common nCino integration patterns

Pattern 1: Synchronize loan applications with a core banking platform

When to use this pattern

Use this pattern when a core banking or underwriting platform needs current Loan Application, Account, Contact, and Opportunity information from nCino. Incremental timestamps or validated change notifications are preferable to repeatedly extracting the complete dataset.

Integration direction
nCino
Martini
Core banking platform
Example Mapping
nCino FieldCanonical FieldTarget Field
Loan Application.Idapplication.sourceIdapplication.externalReference
Account.Nameapplicant.organizationNamecustomer.legalName
Contact.Emailapplicant.emailcustomer.primaryEmail
Opportunity.StageNamelending.stageapplication.status
Martini implementation pattern

A scheduled Martini workflow retrieves changed objects using a supported modification watermark, follows pagination, and assembles related data. It validates required applicant and application fields, enriches the canonical model with relationship data, applies permitted status rules, writes the result to the core banking platform, and routes rejected records to a retry or remediation path.

Martini capabilities used
  • scheduled workflows
  • API consumption
  • pagination and checkpointing
  • data mapping
  • validation and business rules
  • error handling

Pattern 2: Send core banking loan updates to nCino

When to use this pattern

Use this pattern when booking, funding, balance, repayment, or servicing changes originate in a core banking or loan-servicing platform and must update a configured Loan or related nCino object.

Integration direction
Core banking platform
Martini
nCino
Example Mapping
nCino FieldCanonical FieldTarget Field
loan.externalIdloan.sourceIdLoan.External_Id__c or configured external identifier
loan.statusloan.statusLoan.Status__c or configured status field
loan.currentBalanceloan.balanceLoan.Balance__c or configured balance field
loan.bookedDateloan.bookedDateLoan.Booked_Date__c or configured date field
Martini implementation pattern

A Martini API receives the source update, validates the correlation and financial fields, transforms the payload to the configured nCino or Salesforce API names, and performs an idempotent update or upsert. Correlation identifiers prevent duplicate processing, while transient API failures are retried and validation or permission failures are sent for remediation.

Martini capabilities used
  • exposed REST APIs
  • API consumption
  • data transformation
  • idempotency
  • business rules
  • retry and error handling

Pattern 3: Coordinate loan documents and collateral

When to use this pattern

Use this pattern when application or Collateral changes require document metadata or files to move between nCino, Salesforce Files, and a document-management platform. The storage model must be confirmed before implementation.

Integration direction
nCino
Martini
Document-management platform
Example Mapping
nCino FieldCanonical FieldTarget Field
Collateral.Idcollateral.sourceIdasset.externalReference
ContentVersion.Titledocument.namedocument.fileName
ContentVersion.VersionDatadocument.contentdocument.binaryContent
ContentDocumentLink.LinkedEntityIddocument.parentSourceIddocument.parentReference
Martini implementation pattern

Martini retrieves the relevant Collateral or Loan Application relationship and Salesforce Files metadata, applies file-size, type, and access rules, and transfers content or approved references to the document platform. It records source version and target identifiers, handles large-file operations separately, and routes virus-scanning, permission, or transfer failures without exposing sensitive payloads in logs.

Martini capabilities used
  • workflow orchestration
  • file handling
  • data mapping
  • validation
  • security controls
  • error handling

Pattern 4: Distribute selected nCino changes through events

When to use this pattern

Use this pattern when selected Account, Contact, or lending-related changes need near-real-time distribution to a data warehouse, CRM, notification service, or operational application. Event availability must be validated for each object and business event.

Integration direction
nCino
Martini
Snowflake
Example Mapping
nCino FieldCanonical FieldTarget Field
event.replayIdevent.sourcePositioningestion.eventPosition
Account.Idcustomer.sourceIdcustomer.accountId
Contact.LastModifiedDatecustomer.modifiedAtcustomer.updatedTimestamp
Loan.Statusloan.statusloan.currentStatus
Martini implementation pattern

A Martini API receives Platform Event, Change Data Capture, outbound-message, or custom callback notifications, authenticates and validates them, and records event identifiers for duplicate protection. When notifications are incomplete, the workflow retrieves the current object, maps it to the target model, applies routing rules, and retries recoverable downstream failures.

Martini capabilities used
  • API endpoints
  • webhook consumption
  • event-driven workflows
  • deduplication
  • data mapping
  • monitoring and retry

Applications commonly integrated with nCino

nCino is built on Salesforce technology, so integrations commonly connect its lending and customer processes with banking, document, service, credit, and analytics applications. Availability and scope depend on the customer’s nCino modules, Salesforce configuration, permissions, and third-party agreements.

Application Scenario Direction Martini Pattern
Salesforce nCino runs on and extends Salesforce, making Salesforce customer, workflow, security, and API capabilities central to many enterprise integrations. nCino → Martini → Salesforce Martini can consume Salesforce REST or bulk APIs, normalize nCino and Salesforce objects, and route updates between the platform and other enterprise applications. Permissions, package namespaces, and object availability are validated during implementation.
DocuSign Electronic signatures can support loan documents, disclosures, account opening, and approval packages. nCino → Martini → DocuSign A Martini workflow can retrieve application and borrower data, map signing-envelope metadata, submit the required request through the available API, and return signature status or completed-document references to nCino.
Microsoft Dynamics 365 Organizations may synchronize customer, prospect, relationship, and lending pipeline information when Dynamics 365 is used by another business unit. nCino → Martini → Microsoft Dynamics 365 Martini can expose or consume APIs on both sides, map Account, Contact, and Opportunity data to Dynamics 365 models, apply ownership and status rules, and handle conflicts using stable source identifiers.
ServiceNow Lending operations can create service requests, onboarding tasks, incidents, or support work associated with customer and loan processes. nCino → Martini → ServiceNow Martini can receive selected nCino or Salesforce changes, create or update ServiceNow work items, preserve correlation identifiers, and return task status to the originating workflow.
Experian Credit, identity, or risk-related information may be required during lending workflows where the customer has the relevant service agreement. nCino → Martini → Experian A Martini workflow can validate an application request, call the approved Experian endpoint, transform the response into the configured nCino or Salesforce structure, and route exceptions without logging sensitive values.
MeridianLink Organizations may coordinate lending, consumer-credit, or origination processes across MeridianLink and nCino deployments. nCino → Martini → MeridianLink Martini can orchestrate bidirectional API exchanges, map applicant and loan identifiers, apply status-transition rules, and retry transient failures while routing validation failures for review.
Q2 Digital-banking, account, customer, or servicing information may need to be synchronized with a banking-channel platform. nCino → Martini → Q2 Martini can use scheduled or event-driven workflows to transform Account, Contact, Deposit Account, or servicing data and distribute updates while maintaining source-system identifiers.
Snowflake Account, Contact, loan, application, collateral, and servicing data can support analytics, reporting, regulatory analysis, and enterprise data products. nCino → Martini → Snowflake Martini can extract incremental Salesforce and nCino data through REST or bulk jobs, apply canonical mappings, load curated datasets, and record watermarks and batch outcomes for reconciliation.

How to build a nCino integration in Martini

Objective

Establish access to the correct Salesforce and nCino environment using the authentication and permissions model approved by the implementation team.

Instructions in Martini

  • Configure OAuth 2.0 or JWT bearer authentication as appropriate.
  • Store client credentials, certificates, tokens, and environment-specific endpoints as secure configuration.
  • Confirm connected-app scopes, object permissions, field-level security, sharing access, and nCino permission sets.
  • Test access separately in sandbox and production environments.

Objective

Select a scheduled, API-led, bulk, asynchronous, or event-driven trigger based on latency, volume, and event availability.

Instructions in Martini

  • Use a scheduler and incremental watermark for periodic synchronization.
  • Use a Martini API for updates initiated by a core banking or external system.
  • Use configured Salesforce event notifications only after object and event coverage is confirmed.
  • Use Bulk API jobs for migration, reconciliation, or high-volume workloads.

Objective

Retrieve the required nCino and Salesforce objects while respecting pagination, job state, API limits, and package-specific object names.

Instructions in Martini

  • Query only the fields required by the integration.
  • Follow REST continuation links or the appropriate bulk-result process.
  • Retrieve related Account, Contact, Opportunity, Loan Application, Loan, or Collateral data deliberately.
  • Persist watermarks, job identifiers, event positions, and correlation identifiers.

Objective

Coordinate API calls, event handling, transformation, validation, target writes, and exception routes in a maintainable Martini workflow.

Instructions in Martini

  • Separate retrieval, normalization, business rules, target writes, and notification steps.
  • Use reusable workflow logic for common authentication, pagination, and error handling.
  • Branch for partial success, missing permissions, rejected records, and recoverable service failures.
  • Keep source and target identifiers available throughout the workflow.

Objective

Convert Salesforce and nCino payloads into the target application model while accounting for package namespaces, custom fields, and tenant-specific configuration.

Instructions in Martini

  • Map actual API names rather than relying on Salesforce display labels.
  • Normalize dates, statuses, identifiers, amounts, relationships, and document metadata.
  • Use canonical fields where multiple target systems consume the same nCino data.
  • Validate required fields and preserve source identifiers for reconciliation.

Objective

Enforce operational, lending, security, and data-quality rules before changing downstream systems or nCino records.

Instructions in Martini

  • Apply permitted status transitions and ownership rules.
  • Reject or quarantine incomplete applications and unauthorized updates.
  • Use external identifiers and deterministic upsert behavior to prevent duplicates.
  • Avoid logging sensitive loan, customer, credit, or financial-statement payloads.

Common nCino data objects used in integrations

ObjectTypical UseCommon target systemsMartini handling
AccountRepresents a business, organization, household, or other customer relationship and provides a foundation for customer and relationship data.CRM, core banking platforms, data warehouses, customer-service applicationsMartini retrieves or receives Account changes, maps Salesforce and nCino fields to a canonical customer model, applies ownership and status rules, and performs idempotent upserts.
ContactRepresents an individual associated with an Account, loan relationship, or banking process.CRM, customer-service platforms, digital banking, data warehousesMartini maps identity and relationship fields, validates sensitive attributes, preserves source identifiers, and routes incomplete or unauthorized updates for remediation.
OpportunitySupports prospective or active lending pipeline processes in Salesforce and nCino implementations.CRM, lending platforms, analytics platforms, reporting storesMartini synchronizes stage, amount, ownership, and relationship data, applies permitted status transitions, and handles duplicate or partial updates using stable identifiers.
Loan ApplicationRepresents an application and its associated lending workflow; exact API names vary by package and configuration.Core banking, underwriting services, document platforms, data warehousesMartini retrieves incremental changes or processes events, maps applicant and application data, validates required fields, and records correlation and processing outcomes.
LoanRepresents an approved or booked lending relationship, including configured status, terms, balances, or servicing information.Core banking, loan servicing, finance, analytics platformsMartini can receive servicing updates through an API, transform them into the configured nCino structure, apply idempotent upsert logic, and route rejected records for review.
CollateralRepresents assets associated with a loan or credit relationship, such as real estate, vehicles, or other pledged assets.Core banking, valuation services, document platforms, data warehousesMartini maps collateral identifiers, values, relationships, and status fields, coordinates related documents where required, and applies validation before downstream writes.

Authentication and security considerations

Salesforce-based authentication

nCino integrations generally use the authentication configured for the underlying Salesforce environment. OAuth 2.0 is the preferred approach for connected applications, while JWT bearer flow can support unattended integrations when a connected app and signing certificate are configured.

Permissions and environment controls

Authentication alone does not provide access to nCino data. Connected-app scopes, profiles, permission sets, object permissions, field-level security, sharing rules, nCino package permissions, and environment-specific endpoints all affect access.

Protecting sensitive data

  • Store credentials, tokens, certificates, and endpoints in secure configuration.
  • Apply least-privilege access for integration users.
  • Protect loan, customer, credit, and financial-statement data.
  • Avoid writing sensitive payloads to workflow logs.

Operational considerations for nCino integrations

Limits and pagination

Salesforce API requests are subject to org, user, concurrency, and Bulk API limits. Use selective queries, follow continuation links, batch high-volume operations appropriately, and monitor consumption.

Incremental and idempotent processing

Use a supported modification watermark such as SystemModstamp where appropriate, or use validated event positions. External identifiers, correlation IDs, and deterministic upserts help distinguish a failed request from a successful request whose response was lost.

Partial success and retries

Bulk and composite operations may return item-level failures. Inspect each result, retry only recoverable errors, and route validation, permission, schema, and data-quality failures for remediation.

Schema and event changes

API names, namespaces, fields, permissions, package versions, event coverage, and document storage models can vary by tenant and release. Test sandbox and production configurations separately and verify replay, ordering, retention, and duplicate-delivery behavior.

Files and privacy

Large files may require separate operations, and document permissions, versioning, scanning, and retention should be addressed before synchronizing Salesforce Files. Protect sensitive workflow data throughout processing.

Why use Martini instead of scripts or point-to-point integrations?

Orchestrate more than API calls

Scripts can perform individual requests, but Martini provides a structured workflow for authentication, pagination, event intake, transformation, validation, business rules, target writes, and exception routing.

Adapt to Salesforce and nCino variation

nCino object names, namespaces, fields, permissions, licensed modules, and package versions can differ between environments. Martini keeps mappings and environment-specific configuration explicit and reusable rather than embedding them across point-to-point scripts.

Operate reliably

  • Use scheduled, API-led, bulk, asynchronous, or event-driven workflows.
  • Persist checkpoints, correlation identifiers, and synchronization watermarks.
  • Handle pagination, partial success, retries, duplicates, and remediation paths.
  • Expose controlled APIs so downstream systems do not depend directly on package-specific interfaces.

Frequently asked questions

How can nCino be integrated with enterprise systems?

nCino is commonly integrated through the Salesforce platform on which it operates. REST APIs support transactional access, Bulk API and asynchronous operations support high-volume synchronization, SOAP APIs can support existing integrations, Salesforce Files can handle documents, and configured Platform Events, Change Data Capture, outbound messages, Flow, or Apex callbacks can support selected event-driven use cases. Exact objects, fields, events, and permissions depend on the nCino implementation.

Can Martini integrate with nCino?

Yes. Martini can integrate with nCino through the relevant Salesforce or nCino REST APIs, bulk and asynchronous APIs, configured event notifications, SOAP services, and Salesforce Files resources. Martini can authenticate, orchestrate workflows, map and transform data, expose APIs, and apply validation, retry, and monitoring logic. A native Martini nCino connector was not confirmed.

Do I need a connector to integrate nCino with Martini?

No dedicated nCino connector is required. Martini can use nCino's confirmed native integration mechanisms through the underlying Salesforce environment, including REST, bulk and asynchronous APIs, configured callbacks, SOAP where required, file resources, and Salesforce authentication methods.

Is there any extra Lonti cost to integrate nCino with Martini?

Lonti does not charge an additional per-connector or per-vendor fee to integrate nCino. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from nCino, Salesforce, cloud infrastructure, or other third-party systems based on subscription, usage, and deployment model.

Which nCino integration methods should be used for new projects?

REST APIs are generally the starting point for transactional integrations, while Bulk API and asynchronous operations are better suited to migrations, reconciliation, and high-volume synchronization. SOAP may be retained for existing dependencies. GraphQL should be used only if the required nCino data is confirmed to be available through the target Salesforce GraphQL service.

Can Martini receive nCino events or webhooks?

Martini can expose an API and receive webhook-style HTTP requests. nCino and Salesforce implementations may use Platform Events, Change Data Capture, outbound messages, Flow, Apex callouts, or custom callbacks, but coverage is implementation-dependent. Event availability, retention, ordering, replay behavior, and the supported nCino objects should be confirmed for each deployment.

How does synchronization handle mapping, duplicates, and errors?

Martini workflows can map Salesforce and nCino objects into canonical and target models, apply validation and business rules, and use timestamps or event positions for incremental synchronization. External IDs, source identifiers, and correlation values support idempotent upserts and duplicate protection. Retries can be limited to recoverable failures, while partial bulk results, permission errors, and validation failures can be routed for remediation.

Can Martini expose an API façade for nCino?

Yes. Martini can expose a controlled REST API that abstracts selected nCino or Salesforce objects and operations from consuming applications. The façade can enforce authentication and authorization, validate requests, apply business rules, transform payloads, orchestrate multiple calls, and prevent downstream systems from depending directly on package-specific API names.