.png)
Jack Henry Symitar Integration Guide
Integrate Symitar with enterprise applications through SymXchange SOAP services, selected Jack Henry APIs, approved files, and controlled Martini workflows.
Jack Henry Symitar integration options at a glance
Symitar integrations primarily use SymXchange, Jack Henry’s SOAP-based service interface for accessing and updating selected core-processing data and operations. Jack Henry also provides API products through its developer ecosystem, although REST coverage and applicability to Symitar depend on the selected product and institution configuration. General-purpose webhooks for all member, account, share, loan, and transaction changes were not confirmed, so scheduled polling, bounded queries, PowerOn programs, or approved batch interfaces may be required. Martini can consume SOAP and REST APIs, process XML, manage environment-specific credentials, transform data, orchestrate workflows, expose REST façades, and apply validation, retry, reconciliation, and audit controls.
| Integration point | Supported by Jack Henry Symitar? | Common use cases | How Martini supports it |
|---|---|---|---|
| SOAP APIs | Yes | SymXchange exposes WSDL-defined SOAP services for supported Member, Account, Share, Loan, Transaction, and related operations. Availability depends on the institution’s deployment, licensing, and permissions. | Martini can consume SOAP services, manage endpoint configuration, process XML and SOAP faults, map responses, and orchestrate multi-step workflows. |
| REST APIs | Limited | Jack Henry provides APIs through its developer ecosystem, but REST coverage and applicability to Symitar depend on the selected API product and institution configuration. | Martini can consume confirmed Jack Henry REST APIs and apply authentication, mapping, validation, retries, and controlled downstream delivery. |
| Webhooks / outbound callbacks | Not confirmed | A general Symitar webhook facility for all Member, Account, Share, Loan, and Transaction changes was not confirmed. Polling or approved batch interfaces may be required. | Martini can receive webhooks when an approved Jack Henry or adjacent system provides them, but a Symitar-wide event feed should not be assumed. |
| Bulk / async / batch APIs | Limited | Service-specific request patterns, PowerOn programs, or batch processes may be available, but a universal SymXchange bulk API was not confirmed. | Martini can orchestrate bounded batches, scheduled workflows, staged processing, retries, and reconciliation when the institution confirms an approved batch interface. |
| File / attachment APIs | Not confirmed | No general SymXchange file or attachment API was confirmed. Institution-specific or separately licensed Jack Henry file interfaces may exist. | Martini can process approved files through supported file workflows, but the file interface, format, delivery method, and ownership must be confirmed first. |
| Database / analytics access | Limited | Direct production database access should not be assumed. Approved reporting, replication, warehouse, or analytics interfaces depend on the deployment. | Martini can consume approved reporting interfaces or write transformed data to an authorized database, without treating direct core-database access as the default. |
| Authentication | Yes | SymXchange uses institution-configured service authentication and authorization. Jack Henry developer APIs may use application registration, subscriptions, scopes, or OAuth 2.0-style credentials. | Martini stores credentials and endpoint configuration as environment-managed secrets and applies the confirmed authentication model per integration. |
How Jack Henry Symitar exposes data and business events
SymXchange SOAP APIs
SymXchange is the principal Symitar integration mechanism. It exposes WSDL-defined SOAP services for selected Symitar data and operations, with availability determined by the institution’s version, licensed modules, enabled services, security configuration, and permissions.
Martini implementation pattern
Martini implementation pattern: Martini consumes the confirmed WSDL service, stores endpoint and credential configuration outside workflow logic, sends bounded requests, parses XML responses and SOAP faults, maps the result into a canonical model, and invokes downstream APIs or persistence workflows.
Implementation sequence
Jack Henry REST APIs
Jack Henry provides API products through its developer ecosystem, but REST applicability to Symitar depends on the selected product, subscription, authentication model, and institution configuration. SymXchange itself is generally SOAP-based.
Martini implementation pattern
Martini implementation pattern: Martini consumes only the confirmed Jack Henry REST product, applies its required application registration, scopes, subscription, or OAuth-style credentials, and separates product-specific payload handling from reusable workflow orchestration.
Implementation sequence
Scheduled Symitar synchronization
A general-purpose Symitar webhook facility covering all core data changes was not confirmed. Scheduled retrieval using SymXchange, approved reporting feeds, PowerOn programs, or batch interfaces may therefore be required.
Martini implementation pattern
Martini implementation pattern: A scheduler starts a workflow that retrieves bounded Member, Account, Share, Loan, or Transaction data, uses date ranges or stable identifiers where supported, deduplicates overlapping results, and records a high-water mark or reconciliation state.
Implementation sequence
Approved batch or file interfaces
A universal SymXchange bulk API and general-purpose SymXchange file or attachment API were not confirmed. Some institutions may use PowerOn programs, approved exports, or separately licensed Jack Henry file processes.
Martini implementation pattern
Martini implementation pattern: Martini receives or retrieves only institution-approved batch output, validates its format and control totals, transforms the records, stages exceptions, and publishes a reconciliation result. The exact file contract and delivery mechanism must be confirmed before implementation.
Implementation sequence
Common Jack Henry Symitar integration patterns
Pattern 1: Sync members and accounts to a CRM
When to use this pattern
Use this pattern when relationship-management or service teams need current Member, Account, Share, and selected Loan information outside the core. Because broad Symitar webhooks were not confirmed, the workflow typically uses scheduled, bounded retrieval with incremental filters where available.
Integration direction
Example Mapping
| Jack Henry Symitar Field | Canonical Field | Target Field |
|---|---|---|
| Member.memberNumber | member.id | Salesforce Member Identifier |
| Member.firstName / lastName | member.name | Contact First Name / Last Name |
| Account.accountNumber | account.id | Account External ID |
| Share.balance | deposit.balance | Financial Account Balance |
Martini implementation pattern
A scheduled Martini workflow calls the confirmed SymXchange operations, converts SOAP/XML into a canonical model, validates member and account identifiers, and upserts CRM records. Stable source keys, overlapping windows, retry handling, and a checkpoint prevent duplicate or missed updates.
Martini capabilities used
- scheduled workflows
- SOAP API consumption
- XML processing
- data mapping
- business rules
- idempotent writes
- error handling
Pattern 2: Synchronize loans and signing workflows
When to use this pattern
Use this pattern when loan status and approved loan information must coordinate with a lending portal or document-signing process. Exact Loan operations and fields must be confirmed in the institution’s WSDL and permissions.
Integration direction
Example Mapping
| Jack Henry Symitar Field | Canonical Field | Target Field |
|---|---|---|
| Loan.loanId | loan.id | DocuSign External Reference |
| Loan.status | loan.status | Envelope Workflow Status |
| Loan.amount | loan.amount | Envelope Metadata Amount |
| Member.memberNumber | member.id | Recipient or Workflow Member Reference |
Martini implementation pattern
Martini retrieves eligible Loan and Member data, applies status and authorization rules, and invokes the approved document workflow. Signing outcomes are validated before being routed to downstream systems, while transient failures are retried and incomplete cases are placed in an exception path.
Martini capabilities used
- workflow orchestration
- SOAP API consumption
- data mapping
- business rules
- REST API exposure or consumption
- validation
- retry and exception handling
Pattern 3: Reconcile transactions and balances
When to use this pattern
Use this pattern when Transaction activity and related Share or Loan balances must be delivered to reporting, fraud-monitoring, or member-facing systems. Financial corrections, reversals, and backdated activity require replay and reconciliation rather than timestamp-only processing.
Integration direction
Example Mapping
| Jack Henry Symitar Field | Canonical Field | Target Field |
|---|---|---|
| Transaction.transactionId | transaction.id | Transaction Source ID |
| Transaction.postDate | transaction.postedAt | Posted Date |
| Transaction.amount | transaction.amount | Amount |
| Share.balance / Loan.balance | account.balance | Current Balance |
Martini implementation pattern
A scheduled Martini workflow queries bounded transaction windows, uses a date-plus-sequence or stable-identifier high-water mark where available, normalizes XML, and writes curated data to an approved reporting layer. It records counts, totals where appropriate, reversals, retries, and reconciliation exceptions.
Martini capabilities used
- scheduled workflows
- SOAP API consumption
- XML processing
- transformation
- idempotency
- reconciliation
- monitoring and error handling
Pattern 4: Expose a controlled Symitar REST façade
When to use this pattern
Use this pattern when downstream applications need a stable JSON API without direct access to SymXchange endpoints, SOAP details, or Symitar credentials. It is appropriate for narrowly scoped Member, Account, Loan, or balance operations.
Integration direction
Example Mapping
| Jack Henry Symitar Field | Canonical Field | Target Field |
|---|---|---|
| REST request.memberId | member.id | SymXchange Member Identifier |
| REST request.accountId | account.id | SymXchange Account Identifier |
| SymXchange Share.balance | account.balance | REST response.balance |
| SOAP fault | integration.error | REST error response |
Martini implementation pattern
Martini exposes a secured REST API, validates and authorizes requests, invokes one or more permitted SymXchange operations, maps XML to a stable JSON contract, filters sensitive fields, and centralizes logging and error handling. The façade prevents callers from receiving core credentials or deployment-specific SOAP details.
Martini capabilities used
- REST API exposure
- authentication and authorization
- SOAP API consumption
- XML-to-JSON transformation
- validation
- field-level filtering
- error handling
Applications commonly integrated with Jack Henry Symitar
Symitar can be integrated with adjacent banking, service, lending, analytics, and digital-experience products through approved interfaces. The exact operations, fields, permissions, and direction of exchange depend on the credit union’s SymXchange configuration, licensed modules, and participating application.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize member profiles, account relationships, selected loan information, and service activity with relationship-management teams. | Jack Henry Symitar → Martini → Salesforce | A scheduled Martini workflow retrieves Members, Accounts, Shares, and selected Loans through SymXchange, maps them to Salesforce objects, validates identifiers, and performs idempotent writes. Approved Salesforce-initiated updates can be routed back through permitted SymXchange operations. |
| Microsoft Dynamics 365 | Make member and lending information available to relationship managers and customer-service users. | Jack Henry Symitar → Martini → Microsoft Dynamics 365 | Martini polls bounded SymXchange queries, converts SOAP/XML into a canonical model, applies field-level business rules, and synchronizes Dynamics 365. Failures are isolated and retried without repeating completed writes. |
| ServiceNow | Create service cases and operational workflows from approved member, account, or transaction-related information. | Jack Henry Symitar → Martini → ServiceNow | A scheduled or API-triggered Martini workflow retrieves relevant Symitar data, validates service-case criteria, creates or updates ServiceNow records, and stores source identifiers for deduplication. Because general Symitar webhooks were not confirmed, change detection may use polling or an approved batch feed. |
| DocuSign | Coordinate document-signing processes for loans, account servicing, and member agreements. | Jack Henry Symitar → Martini → DocuSign | Martini retrieves eligible Loan or Account information, prepares a controlled DocuSign request through the approved document workflow, and routes signing status to downstream processes. Sensitive fields are minimized and signing outcomes are reconciled with the source workflow. |
| Plaid | Support member-authorized account verification, aggregation, or funding workflows where the institution has approved the product scope. | Plaid → Martini → Jack Henry Symitar | Martini receives approved Plaid results, validates member and account correlation, applies authorization rules, and invokes permitted SymXchange operations. Errors, consent boundaries, and duplicate submissions are recorded for review. |
| Fiserv DNA | Support data exchange during core-system coexistence, migration, or credit-union merger programs. | Jack Henry Symitar → Martini → Fiserv DNA | Martini orchestrates bounded extraction and transformation between the two core platforms, applies mapping and reconciliation rules, and stages exceptions for controlled migration review. Direct bilateral operations are enabled only where each platform provides approved interfaces. |
| Microsoft Power BI | Deliver curated member, loan, share, and transaction data for reporting and analytics. | Jack Henry Symitar → Martini → Microsoft Power BI | Martini retrieves approved SymXchange or reporting data, normalizes SOAP/XML payloads, writes a curated warehouse or reporting dataset, and supports Power BI consumption. Reconciliation totals and extraction windows are retained for auditability. |
| Jack Henry Banno | Coordinate core member and account data with Jack Henry digital-banking experiences where the institution uses the relevant product entitlements. | Jack Henry Symitar → Martini → Jack Henry Banno | Martini mediates approved exchanges between SymXchange and Jack Henry digital-banking services, applying canonical mappings, permissions, and reconciliation. Exact interfaces and product entitlements must be confirmed with Jack Henry and the credit union. |
How to build a Jack Henry Symitar integration in Martini
Objective
Confirm the institution’s SymXchange or Jack Henry API endpoint, WSDL, network controls, service permissions, and authentication requirements before building the workflow.
Instructions in Martini
- Confirm the approved interface and enabled Symitar services
- Store endpoint URLs, credentials, certificates, and scopes in environment-managed configuration
- Use least-privilege service accounts and approved TLS or network controls
- Keep secrets out of workflow definitions, source control, and logs
Objective
Select a trigger that matches the vendor’s confirmed event coverage and the institution’s operational constraints.
Instructions in Martini
- Use a Martini API trigger for controlled request-response integrations
- Use a scheduler when Symitar changes must be polled
- Use an approved batch or file trigger when the institution supplies an export
- Do not assume a general Symitar webhook exists
Objective
Call the confirmed SymXchange SOAP operation or Jack Henry REST resource using bounded, institution-approved retrieval criteria.
Instructions in Martini
- Retrieve only the required Member, Account, Share, Loan, or Transaction fields
- Use identifiers, date ranges, pagination, continuation mechanisms, or high-water marks where supported
- Inspect SOAP faults and application-level status fields
- Avoid unbounded full-core scans
Objective
Coordinate retrieval, transformation, validation, target writes, and checkpoint management as a maintainable Martini workflow.
Instructions in Martini
- Separate vendor-specific calls from reusable business logic
- Route invalid or incomplete records to an exception path
- Sequence dependent calls such as Member, Account, Share, or Loan lookups
- Persist extraction windows and processing state
Objective
Convert SOAP/XML or confirmed REST payloads into a canonical model suitable for downstream applications and reporting layers.
Instructions in Martini
- Map stable Symitar identifiers to canonical keys
- Normalize dates, statuses, amounts, balances, and optional fields
- Apply field-level filtering for sensitive member and financial data
- Use explicit XML namespace and schema handling
Objective
Enforce business, authorization, reconciliation, and data-quality rules before writing to downstream systems or invoking updates.
Instructions in Martini
- Validate required identifiers and permitted operation scope
- Apply status, eligibility, consent, and duplicate-detection rules
- Handle reversals, corrections, backdated transactions, and closed accounts
- Reject or quarantine records that fail business validation
Common Jack Henry Symitar data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Member | Synchronize credit-union member profiles and identifying information. | Salesforce, Microsoft Dynamics 365, ServiceNow, data warehouses, digital-banking applications | Martini retrieves permitted fields through SymXchange, validates identifiers, maps SOAP/XML to canonical JSON, and performs idempotent create or update operations. |
| Account | Represent a member’s account relationship, status, and related services. | Salesforce, Microsoft Dynamics 365, digital-banking applications, reporting platforms | Martini uses institution-approved operations, applies field-level filtering, and records source identifiers and synchronization checkpoints. |
| Share | Synchronize deposit/share account identifiers, balances, and status. | Data warehouses, Power BI reporting layers, member portals, fraud-monitoring processes | Martini retrieves bounded data, normalizes balances and statuses, protects sensitive fields, and reconciles counts or totals where appropriate. |
| Loan | Coordinate loan balances, payment details, status, and lending workflow information. | Lending portals, Salesforce, DocuSign workflows, Microsoft Dynamics 365, reporting platforms | Martini validates loan eligibility and status rules, maps XML fields, routes approved updates, and handles retries and reconciliation. |
| Transaction | Synchronize financial activity affecting Shares, Loans, and other accounts. | Fraud-monitoring processes, data warehouses, Power BI, member-facing applications | Martini uses stable identifiers and high-water marks, supports overlapping windows, detects reversals and corrections, and makes downstream writes idempotent. |
| User | Represent Symitar user or service-user context used for access control and service invocation. | Integration configuration, audit processes, access-control workflows | Martini keeps service credentials and authorization configuration in managed secrets, limits workflow access, and avoids exposing credentials in payloads or logs. |
Authentication and security considerations
Deployment-specific authentication
SymXchange authentication and authorization depend on the credit union’s configuration. Service accounts, Symitar user credentials, institution or accounting-unit context, service permissions, TLS, network restrictions, and endpoint controls may all be relevant. Jack Henry developer APIs can use different application registration, subscription, scope, or OAuth 2.0-style requirements; OAuth should not be assumed for SymXchange.
Least privilege and secrets
- Use dedicated service accounts with only the required Member, Account, Share, Loan, and Transaction permissions.
- Store credentials, certificates, endpoints, and API configuration in Martini environment-managed secrets.
- Restrict logs and retained payloads because member, loan, account, and transaction data may contain regulated information.
- Use approved encryption, TLS, network allowlisting, and access-control policies.
Operational considerations for Jack Henry Symitar integrations
Bounded retrieval
Coordinate request rates with the credit union and Jack Henry support teams. Prefer bounded queries, incremental filters, pagination, continuation mechanisms, or approved batch interfaces over unbounded core scans.
Correctness and resilience
- Use stable identifiers and idempotency controls for create and update operations.
- Handle SOAP faults, application-level errors, transient failures, retries, and partial completion separately.
- Use overlapping extraction windows and deduplication when no reliable change feed exists.
- Account for reversals, corrections, backdated transactions, deleted or closed accounts, and replay.
- Maintain reconciliation counts, totals where appropriate, extraction windows, checkpoints, and failed-record queues.
Contracts and testing
WSDLs, namespaces, enabled services, fields, enumerations, and permissions can vary by institution and Symitar version. Maintain contract tests against the target environment and treat WSDL or schema changes as controlled releases.
Why use Martini instead of scripts or point-to-point integrations?
Centralized integration logic
Martini keeps SymXchange-specific SOAP handling, XML transformation, authentication, business rules, downstream mappings, and exception paths in maintainable workflows rather than scattering them across scripts or point-to-point code.
Controlled APIs and reuse
Martini can expose stable REST façades, reuse mapping and validation logic, and isolate vendor-specific contracts from consuming applications. This reduces direct access to Symitar credentials and makes institution-specific configuration explicit.
Operational visibility
Scheduled orchestration, checkpoints, retries, idempotency, reconciliation, logging, and environment-managed secrets provide a consistent operating model for financial data synchronization and API-led integration.
Frequently asked questions
Symitar is commonly integrated through SymXchange SOAP web services, which expose WSDL-defined operations for selected core data and activities. Depending on the institution and selected Jack Henry product, integrations may also use Jack Henry REST APIs, approved batch or file interfaces, PowerOn programs, or reporting feeds. Scheduled polling may be necessary because a general webhook facility for all core changes was not confirmed.
Yes. Martini can consume the institution’s confirmed SymXchange SOAP services, process XML, invoke applicable Jack Henry REST APIs, orchestrate scheduled synchronization, transform data, and expose controlled REST APIs for downstream applications. Exact capabilities depend on the institution’s WSDL, licenses, permissions, and network configuration.
No. A dedicated Jack Henry Symitar connector is not required. Martini can integrate using SymXchange SOAP services and, where confirmed, Jack Henry REST APIs, approved files, batch processes, or reporting interfaces. A native Martini Symitar connector was not confirmed in the supplied research.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Jack Henry Symitar. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from Jack Henry, the credit union’s infrastructure, or other third-party systems depending on subscriptions, usage, licensing, and deployment model.
SymXchange SOAP is generally the primary Symitar-specific method because it provides WSDL-defined services for supported operations. Confirmed Jack Henry REST products can be used where their coverage applies to the required Symitar workflow. Approved batch, PowerOn, reporting, or file interfaces may supplement the API when they are available and institutionally authorized.
A general-purpose Symitar webhook or callback facility covering all Member, Account, Share, Loan, and Transaction changes was not confirmed. Integrations should use scheduled polling, approved batch exports, or institution-specific interfaces unless Jack Henry confirms an applicable event mechanism for the required data domain.
Martini can run scheduled workflows that retrieve bounded data using identifiers, date filters, pagination, or other mechanisms supported by the specific service. It can map SOAP/XML into canonical models, use stable identifiers and high-water marks, apply idempotent writes, and maintain checkpoints, reconciliation totals, and exception records. Transaction flows should account for reversals and corrections.
Yes. Martini can expose a secured REST API that validates requests, invokes permitted SymXchange operations, maps SOAP/XML responses into stable JSON contracts, filters sensitive fields, and centralizes authorization, logging, and error handling. This prevents downstream applications from needing direct access to Symitar credentials or deployment-specific SOAP details.
Related Martini documentation
Workflows
Integrate Jack Henry Symitar with Martini
Use Martini to connect approved Symitar services with enterprise applications through secure APIs, scheduled workflows, reusable mappings, controlled REST façades, and operational safeguards.