Development using SOAP

OAuth jXchange SOAP Access

JH is now using OAuth 2.0 authentication to access jXchange APIs. Documentation for this change is now available. All new bank level implementations will use OAuth starting in April 2026 and all implementations will be mandated to convert to OAuth by April 2028.

This page has been updated to reflect the new OAuth requirements for SOAP. For more topical information and frequently asked questions about the change, we have created the SOAP Authentication Changes page.

SOAP Authentication Update  

Introduction

This information is to help jump start your development as a new consumer of jXchange Service Gateway (jXchange). Please review all the information below, as well as the related documentation listed under the “Minimal document reading requirements” and “Optional reading if relevant to project” sections before starting a new development effort.

The Use Case responses provided below are a good starting place for your development, but please note that additional discussion and rewrites are possible as we work through the onboarding process.

This information is not intended to be a comprehensive list for all operations and behaviors as there are other documents that fulfill that requirement.

As a new consumer of Enterprise Integration & Services (EI&S) services, your company will be responsible for the complete development life cycle of your new product. Jack Henry(JH) does not provide code reviews, nor do we require code supervision for your product.

jXchange Service Gateway is our native SOAP interface and payloads are formatted in XML. We do offer REST over SOAP using a translation layer in Mulesoft. If REST is the preferred method, the documentation for the SOAP APIs will still be pertinent to complete your development since the JSON message structure formatting will follow the XML message structure.

Jack Henry application programming interfaces (API) are developed as contract-first, meaning the structure is designed prior to the supporting service. The primary reason being the contracts are designed with the enterprise perspective, ensuring all potential providers of the services are represented.

IMPORTANT: WSDLs that can be found in the Documentation page. The file name contains the contract version, using this name format - TPG_RYYYY.X.XX_XSD.

Environment access

The JH environment utilizes OAuth 2.0 for authorization. Consumers are expected to have a basic understanding of its usage.

The information below may be used to send operations to our externally accessible jXchange instance. This sandbox institution that is commonly referred to as the DMZ. This instance is used by third parties, financial institutions and some internal JH groups to develop their jXchange integrations.

Public and Private Key Pair/JWKS URI

Obtaining access to the JH environment will require a consumer to create a public/private key pair and to provide the public key to the respective JH team. Additionally, a consumer may use the JWKS URI to provide the public key portion of the pair.

Once the public key/JWKS URI is received, the JH team will configure the appropriate providers requested and provide any provider specific values that are required.

JSON Web Token

Once configured for access, the consumer will obtain a JSON Web Token (JWT) from the JH token server. The provided token is used as the credentials for making the API request. JH has set a 10 minute time limit for token expiration. Once a token expires,a new token will need to be requested.

General Access Values

Detailed Information

For more detailed information on tokens and Jack Henry’s authentication workflow, please visit our Authentication Framework Client Credentials page.

DMZ Institution Cores

The InstRtID and InstEnv values above denote three different jXchange configurations, each tied to a different JH core provider. The DMZ jXchange currently tied to SilverLake uses 011001276 and TEST or Ovation, the CIF2020 gateway uses 2020 and TEST, and Core Director uses 11111900 and TEST.

Your provisioned access to these gateways may vary depending on which core(s) your company identified for use in the initial onboarding documentation.

For all jXchange integrations, the combination of InstRtId and InstEnv values will be unique to each jXchange instance.

jXchangeHdr

The jXchangeHdr structure is required for all jXchange operations. Although most header elements are listed as optional according to the contracts (XSDs), it is expected that they are always populated properly according to their use and the purpose of the consuming product. Certain behaviors and functionality may be adversely impacted if improper values are provided.

For a more detailed description of the jXchangeHdr and its elements, please refer to the jXchangeHdr Information page.

Example jXchange header

<jXchangeHdr>
    <JxVer />
    <AuditUsrId>AuditUsrId</AuditUsrId>
    <AuditWsId>AuditWsId</AuditWsId>
    <AuthenUsrId />
    <ConsumerName />
    <ConsumerProd />
    <Ver_1 />
    <jXLogTrackingId>{GUID}</jXLogTrackingId>
    <Ver_2 />
    <InstRtId>011001276</InstRtId>
    <InstEnv>TEST</InstEnv>
    <Ver_3 />
    <BusCorrelId />
    <Ver_4 />
    <WorkflowCorrelId />
    <Ver_5 />
    <ValidConsmName>{ValidConsmName}</ValidConsmName>
    <ValidConsmProd>{ValidConsmProd}</ValidConsmProd>
    <Ver_6 />
</jXchangeHdr>

1. <JxVer>- the value in this element is informational only and will not be utilized by jXchange, but the response will contain the current version of jXchange. (This field may be blank.)
2. <AuditUsrId> and <AudiWsId> - These are not required and can be used to track the username and workstation of the person/agent making the request. (This field may be blank.)
3. <ConsumerName> and <ConsumerProd> - These are independent of <ValidConsmName> and <ValidConsmProd> and should not be populated unless directed by JH. (These fields should be blank unless directed by JH resource.)
4. <jXLogTrackingId> should be a new unique value, preferably a GUID for every operation call. Having a unique value in jXLogTrackingId is extremely valuable for researching issues in a bank’s environment. (This should not be blank.)
5. <InstRtId> and <InstEnv> are the bank’s ABA/routing number and the bank’s core environment (UAT, TEST, etc.). (Required.)
6. <BusCorrelId> is used to group multiple units of work. This might include several calls used to add a new customer with an associated new account.(This field may be blank.)
7. <WorkflowCorrelId> is reserved for JH workflow application services. Please refer to the jXchangeHdr Information page for more information. (This field may be blank.)
8. <ValidConsmName> and <ValidConsmProd> elements are required that are provided to you by JHA and will be used for all integrations in development and production locations. (Required.)
9. <Ver_*> - These tags are required throughout the jXchangeHdr and the XML. Their placement is exact as they are used to mark a code change that has occurred in the XML and allows for backwards compatibility. (Required as part of the call, though the fields will be self closed as shown in above sample.)

CustSrch sample XML for SilverLake core

HTTP header

• POST /jxchange/2008/ServiceGateway/ServiceGateway.svc HTTP/1.1
• Host: jxdmz.jackhenry.com
• Content-Type: text/xml; charset=UTF-8
• Content-Length: 2607
• SOAPAction: http://jackhenry.com/ws/CustSrch
• Authorization: Bearer ‘JWT Token’

Request

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope
    xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <SOAP-ENV:Header>
    </SOAP-ENV:Header>
    <SOAP-ENV:Body>
        <CustSrch
            xmlns="http://jackhenry.com/jxchange/TPG/2008">
            <SrchMsgRqHdr>
                <jXchangeHdr>
                    <JxVer />
                    <AuditUsrId>AuditUsrId</AuditUsrId>
                    <AuditWsId>AuditWsId</AuditWsId>
                    <AuthenUsrId />
                    <ConsumerName />
                    <ConsumerProd />
                    <Ver_1 />
                    <jXLogTrackingId>{GUID}</jXLogTrackingId>
                    <Ver_2 />
                    <InstRtId>011001276</InstRtId>
                    <InstEnv>TEST</InstEnv>
                    <Ver_3 />
                    <BusCorrelId />
                    <Ver_4 />
                    <WorkflowCorrelId />
                    <Ver_5 />
                    <ValidConsmName>{ValidConsumerName} </ValidConsmName>
                    <ValidConsmProd>{ValidConsumerProduct}</ValidConsmProd>
                    <Ver_6 />
                </jXchangeHdr>
                <MaxRec>3999</MaxRec>
                <Cursor />
                <Ver_1 />
                <Ver_2 />
                <Ver_3 />
            </SrchMsgRqHdr>
            <PersonName>
                <ComName />
                <FirstName />
                <MiddleName />
                <LastName>smith</LastName>
                <Ver_1 />
            </PersonName>
            <Ver_1 />
            <Ver_2 />
            <Ver_3 />
            <Ver_4 />
            <Ver_5 />
            <Ver_6 />
        </CustSrch>
    </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Multi-Provider Testing

If a solution will be touching multiple JH providers (ex: Silverlake, CIF 20/20, Core Director, etc.) it is important to understand that although most of the operations are not provider specific and are interchangeable from the consumer standpoint. However, the jXchange environment and its APIs do not provide normalization and behaviors/responses can differentiate a great deal based on the provider that is being accessed. It is the responsibility of the consumer to test their service calls across every provider environment to ensure their product can handle any potential different behavior/responses between individual providers.

A simple example of this can be found in the account types between SilverLake and Core Director. A deposit account for SilverLake uses the identifier of D while Core Director uses the identifier of 10.

DMZ Demonstration Use Statement

Jack Henry’s Integration Sandbox (aka DMZ) is a developer focused environment where all consumers are integrating with shared systems of record, whether banking cores, SilverLake, CIF 2020, Core Director and Episys, or complimentary products such as Synergy and Synapsys. The nature of this environment does not necessarily lend itself to Third Party Vendor product demonstrations utilizing Jack Henry’s Enterprise Integration solutions. Third Party Vendors may use these systems for demonstrations, with the following understanding.

• Data can and may change based on usage and access by other consumers during your demonstration window.
• Access will not be limited to prevent other consumers from using the environment during a window of time.
• Jack Henry personnel will not be available for immediate troubleshooting if issues arise during a demonstration.
• System maintenance is scheduled Monday between 4:00 pm and 6:00 pm US Central time.
• The SilverLake banking core runs its nightly processing Monday through Friday, beginning at 8:00 pm Central and normally completing before 9:00 pm US Central time.
• After hours support is not available for the DMZ. Business hours are 8:00 am to 5:00 pm US Central time.

Sample process flow diagram for jXchange integrations

This is an example flowchart of how a workflow might look and can be modified to meet certain product requirements. Note that the customer record is the root and must exist prior to associating accounts.

Commonly Used APIs, Tutorials and Sample Data

See Commonly Used APIs for a quick list of apis that are most used when consuming jXchange APIs. We also offer a Tutorials section for additional use cases. A full list of APIs may be found within the API by Provider or API by Reference.

Sample data is provided to assist with starting your development journey. Within the SOAP Documentation page, locate the file named DMZTestAccounts_SL_2020_CoreDirector_Episys.

JH Public Postman Collection

For those consumers that wish to test our APIs via Postman without first using development efforts, we offer a public Postman collection of our SOAP APIs. Please reference our JH Postman Public Collection tutorial for more information.