FAQ

Frequently Asked Questions

Does Jack Henry plan to retire jXchange SOAP APIs?

No. This is intended to make the jXchange SOAP APIs more secure.

Are there functional or structural changes to the APIs themselves?

No. Jack Henry is committed to continued support of backwards compatibility with our APIs. This change does not affect that initiative.

Will all Jack Henry Hosted APIs require this new security model?

All APIs accessible over the internet will implement the new security model.

Does this change impact SymXchange APIs?

This update only applies to the Hosted jXchange environments so this excludes all SymXchange instances.

Will Jack Henry provision production credentials?

Institutions will be responsible for provisioning credentials, though there may be exceptions. Configurations on the jXchange product will still require a Jack Henry work effort regardless if an institution or Jack Henry provisions the API credentials.

Does this impact my on-premise (jXchange hosted within an institution’s network) jXchange implementation?

No. This only applies to Jack Henry hosted JX environments

If I have already provided my public and private key to an institution, do I need an additional client?

If you’re currently using the Digital Toolkit Admin API, you may use the existing client configuration to access jXchange API’s, but additional setup is still needed on the jXchange side to authorize that client to the jXchange operations.

Are third parties required to migrate all their bank partners at once?

No. Third party consumers can migrate each bank partner individually, using the old and new security models concurrently before the deadlines.

We currently pass in the wsse security information (username and password) within the SOAP ENV header. Will consumers still need to provide that information within the request?

No. The <wsse:security> section of the older SOAP APIs, i.e. usernames and passwords, will no longer be used with the OAuth security model. Please remove those from your request. More information may be obtained on our Getting Started Development Using SOAP page.

We understand that jXchange Connector has announced that it is being depreciated and will allow new connections after April 30, 2026. Is there additional information you can provide?

This depreciation pertains to the jXchange shift from jConnect to Public IP connection:

Jack Henry has strengthened the security framework of the jXchange Service Gateway by adopting OAuth 2.0—an industry-standard protocol for securing APIs. This enhancement aligns with our transition to a cloud-hosted environment, which brings improved scalability, availability, and resilience to our services. As part of this shift, API calls originating from financial institutions (FIs) will now securely traverse the internet to reach the hosted jXchange environment. Importantly, banks and credit unions will no longer need to manage DNS or networking configurations over jConnect to access the jXchange endpoint—simplifying connectivity and reducing overhead.

However, for scenarios where the hosted jXchange environment needs to communicate with on-premise API providers, a jConnect connection will still be required. While this does involve some configuration effort, it ensures secure and reliable integration between cloud-hosted services and on-prem systems.

Here’s a quick comparison between the two models:

As part of our implementation of your OAuth project, We need a place to publish the JWKS URL. Does Jack Henry (JH) offer a product/service that available for us to host the endpoint?

No. JH does not host other parties endpoints.

Is a JWKS URL required for Fintechs operating within a banking environment? If so, does each institution need a separate JWKS URL?

Yes, JH requires a JWKS (JSON Web Key Set) URL endpoint for Fintechs operating in bank environments. This endpoint enables multiple public keys to be accessible simultaneously, allowing Fintechs to rotate their public/private key pairs without causing downtime for bank operations. The Fintech simply updates their JWKS URL with the new public key, and can then switch to the corresponding private key as needed.

JH does not prescribe how the JWKS URL(s) must be structured or used. It is up to the Fintech and the institution to decide whether the JWKS URL should host keys specific to a single institution or include keys for multiple institutions. Additionally, there is no requirement on the number of JWKS URLs a Fintech must maintain. The only requirement is that each Client ID must be associated with a JWKS URL endpoint. This endpoint may be shared across multiple Client IDs or dedicated to a single institution, depending on the Fintech’s implementation.

I plan to host multiple public keys on my JWKS URL endpoint. How do I specify which key to use when making a token request?

When sending a token request, you should include a “kid” (Key ID) element in the token request header. This “kid” value should correspond to one of the public keys listed in your JWKS URL endpoint. The authorization system uses this “kid” to identify and match the correct public key for validating the token.

If the “kid” is missing from either the token request header or the JWKS endpoint, the system will attempt to match the token against all available keys. While this fallback mechanism works, it can introduce delays in API response times. To ensure optimal performance, it is strongly recommended to include the “kid” element in your token request. This allows the authorization system to quickly locate the correct key and process the request efficiently.

Should we have a separate public/private key per FI?

This is a business decision for each vendor/product and institution - one public/private key pair for each FI or one for everyone.

We’re getting a 502 Bad Gateway error for API requests, even though we can successfully obtain a bearer token from the token endpoint. What could be causing this?

A 502 Bad Gateway error typically indicates that the request is reaching the gateway but cannot connect to the backend service. One common reason for this issue is country restrictions. The country of origin for your requests must be approved by Jack Henry’s OAuth team. If your country is not on the approved list, the API calls will fail even if token generation works. Next Steps:

• Confirm your country of origin with the Jack Henry OAuth team.
• Request approval for your country to be allowed for API access by sending an email to Vendor Relations.