J.P. Morgan Business Direct Connect

Integration guide

Before you begin

Before you start onboarding, make sure you have:

A J.P. Morgan integration contact
Partner registration information
Application registration information
A certificate or JWKS URI
UAT IP addresses for allowlisting

Onboarding overview

Complete the onboarding process in the following order:

Onboard your organization in the UAT environment
Onboard your application in the UAT environment
Onboard to production
Configure connectivity and authentication
Obtain user consent
Exchange authorization codes for tokens
Manage token lifecycles

The lower environment used to test your integration is the UAT (pre-production or test). It is functionally equivalent to production. New functionality is introduced in UAT and promoted to production after validation.

After onboarding is complete and you have a valid access token, your application can connect to J.P. Morgan Digital Banking accounts.

Use these sections to initiate onboarding for your organization and applications. The process is the same for both UAT (test) and production environments. Submit separate requests for each environment.

1. Onboard your organization into the UAT environment

Register your organization as a partner with Business Direct Connect. This partner construct represents your company and serves as the parent entity for all registered applications.

Send the required information to your assigned J.P. Morgan integration team. After registration is complete, you can modify your registration request as needed.

Partner registration

To initiate onboarding, provide these details:

A JSON-formatted registration request using the partner onboarding template:
- Replace partnerName with your firm’s name in all caps with no spaces, as specified in the partnerName field.
- Replace the date suffix with the date the file is generated. Refer to Partner onboarding template table for field descriptions.
A 30x30 logo file in PNG format. This logo is displayed to the end user during the consent flow.
- Name the file using this format: partner_partnerName_yyyymmdd.png.
- partnerName should match the value used in the registration request.
- The date suffix should be the date the file was generated in yyyymmdd format.
A set of IP addresses to be allowlisted in Classless Inter-Domain Routing (CIDR) notation for access to the UAT environment only (Production IPs do not need to be allowlisted):
- IP addresses used to access FDX APIs.
- IP addresses used to request access tokens.
- IP addresses for user machines initiating the consent workflow in a browser.

Modify an existing registration

To modify, delete, or reactivate an existing registration, submit a JSON-formatted request using the partner onboarding template.

Specify the desired action in the action field.
All fields must be specified, and partnerName must match the previously provided value.
For a MODIFY request, the newly provided values will override the previous values. partnerName cannot be modified.
The DELETE action will deactivate the partner record. All related application records are also deactivated.
To reactivate a deleted partner, specify the action as REACTIVATE. The applications will need to be re-registered or reactivated, and the user must provide fresh consent.

Create a partner onboarding request

The partner onboarding table describes the fields included in the partner onboarding request. Save this template as a file and email it to your J.P. Morgan integration team at jpmorgan.business.direct.connect.support@jpmorgan.com.

Name the file using this format: partner_<PARTNERNAME>_<yyyymmdd>.json.
Update the attributes according to the partner onboarding instructions table.
The date suffix should be the date the file was generated, in yyyymmdd format.

Use the partner onboarding template as a reference to construct your request.

Partner onboarding template

Json

{
  "action": "NEW",
  "partnerName": "Unique name in all CAPS with no spaces used to identify the partner records",
  "partnerDisplayName": "Partner name as displayed to the end user",
  "partnerShortName": "Shortened partner name for space constrained displays",
  "requiredPermissions": [
    "ACCOUNT_BASIC",
    "ACCOUNT_DETAILED",
    "TRANSACTIONS",
	"PAYMENT_SUPPORT",
	"STATEMENTS",
	"CUSTOMER_CONTACT"
  ],
  "supportedAccountDomiciles":[
    "US"
  ],
  "contactEmail": "test@amzn.com",
  "reason": "New partner",
  “jwksUri” : “<JWKS URI may be provided in lieu of or in addition to certificate below>”,
  "certificate":"<full leaf certificate from BEGIN CERTIFICATE to END CERTIFICATE>",
  "_version": "5.0"
}

Partner onboarding instructions

Partner onboarding template instructions
Field name	Description
`action`	Specify `NEW`, `MODIFY`, `DELETE`, or `REACTIVATE`.
`partnerName`	Provide a unique name for the partner, in all caps without spaces.
`partnerDisplayName`	Provide the full name displayed to the end user.
`partnerShortName`	Provide the shortened display name displayed to the end user in space-constrained displays.
`requiredPermissions`	Provide a list of data clusters: `ACCOUNT_BASIC` `ACCOUNT_DETAILED` `TRANSACTIONS` `PAYMENT_SUPPORT` `STATEMENTS` `CUSTOMER_CONTACT`
`supportedAccountDomiciles`	Provide country codes, such as U.S. or UK, in ISO 3166 alpha 2-character format.
`contactEmail`	Provide a secure email to receive onboarding information.
`reason`	Provide a reason for the action, such as "New record," or "Updated permissions".
`jwksUri`	A JWKS URI (JSON Web Key Set URI) is a stable, public HTTPS endpoint (typically `https://<your-domain>/.well-known/jwks.json`) that exposes a set of cryptographic public keys used to authenticate incoming requests.
`certificate`	Certificate may be provided but is not required if JWKS URI is provided. It should be signed by a valid certificate authority (CA), generated for the given partner. The partner must follow their organizational procedure for requesting and retrieving a valid CA-signed certificate. For test partners in test environments, a self-signed certificate may be provided instead, as per the instructions below. Only the leaf certificate is needed; don't provide root or intermediate certificates.
`_version`	Must match the version configured within FDX services. As of October 14, 2026, use 5.0 as the version.

2. Onboard your application in the UAT environment

To register your application, submit the required details to your integration team. You can update your registration after it is complete.

Application registration

To register an application, provide these details:

A JSON-formatted registration request using the application onboarding template.
- Replace partnerName with your firm’s name in all caps without spaces, as noted in the template.
- Replace appName with the name of the application in all caps without spaces, as noted in the template.
- Replace the date suffix with the date the file is generated in yyyymmdd format.
- Populate all fields within the template.
- clientId must be provided, except for a new registration.
- Required permissions for an application must be a subset of those for the partner.
A 30x30 logo file in PNG format.
- This logo is displayed to the end user during the consent flow.
- Name the file using this format: application_PartnerName-ApplicationName_yyyymmdd.png.
- partnerName and appName should match the values used in onboarding.
- Replace the date suffix with the date the file was generated in yyyymmdd format.

Upon successful onboarding, clientID is generated for the registered application and sent to the contact email in the partner registration record. Any errors, clarifications, or exceptions are also sent to the same email address.

Modify an existing application registration

To modify, delete, or reactivate a previously registered application, submit a JSON-formatted request using the application onboarding template.

Specify the desired action in the action field.
All fields must be specified.
PartnerName, ClientId, and ApplicationName must match the previously provided values.
For a MODIFY request, the newly provided values will override the previous values. PartnerName, ApplicationName, and ClientId cannot be modified.
DELETE action will deactivate the application's record along with all associated consent records.
To reactivate a deleted application, specify the action as REACTIVATE. The user must provide fresh consent.
If an application is modified to update the RequiredPermissions, the original permissions continue to apply to existing consents. Updated permissions apply only to new consents.

Create an application onboarding request

Use the application onboarding template as a reference to construct your request. Copy this to a file and email it to your J.P. Morgan integration support team.

Refer to the application onboarding template instructions to learn how to construct the request.

Name the file using this format: application_PartnerName-ApplicationName_yyyymmdd.json.
Update the attributes according to the instructions table.
Replace the date suffix with the date the file was generated in yyyymmdd format.

Application onboarding template

Json

{
  "action": "NEW",
  "appName": "UNIQUE_APPLICATION_NAME_IN_ALL_CAPS_WITHOUT_SPACES",
  "clientId": "<PARTNERNAME-APPNAME>",
  "appDisplayName": "<application-display-name>",
  "appShortName": "<application-short-name>",
  "connectionType": "<AGG or DIRECT>",
  "partnerName": "<partner-name must match a valid partner name>",
  "redirectURIs": [
    "redirect URL 1",
    "redirect URL 2"
  ],
  "requiredPermissions": [
    "ACCOUNT_BASIC",
    "ACCOUNT_DETAILED",
    "TRANSACTIONS",
    "PAYMENT_SUPPORT",
    "STATEMENTS",
    "CUSTOMER_CONTACT"
  ],
  "supportedAccountDomiciles": [
    "US"
  ],
  "appWebsiteURI": "app website URL",
  "appSupportedProducts": [
    "Product 1",
    "Product 2"
  ],
  "appMessage": "<optional app-message to display on the consent screen>",
  "reason": "New application",
  "_version": "5.0"
}

The application onboarding table describes the fields included in the application onboarding template:

Application onboarding template instructions
Field name	Description
`action`	Specify `NEW`, `MODIFY`, `DELETE`, `REACTIVATE`
`appName`	Provide a unique application name in all caps without any spaces.
`clientId`	Provide the client identifier that was provided during the initial registration. Leave it blank for new registration.
`appDisplayName`	Provide the full name displayed to end users.
`appShortName`	Provide a shortened display name for limited space.
`connectionType`	Specify `DIRECT` or `AGG`. `DIRECT` implies it is your application. `AGG` implies it is a third-party application that is sourcing data through the partner. In the latter case, both partner and application logos are shown during consent. Otherwise, only the application logo is shown.
`partnerName`	Provide the registered partner name. It must be in ALL CAPS without spaces.
`redirectURLs`	Provide a list of URLs to redirect the user after consent.
`requiredPermissions`	Provide a list of data clusters: `ACCOUNT_BASIC` `ACCOUNT_DETAILED` `TRANSACTIONS` `PAYMENT_SUPPORT` `STATEMENTS` `CUSTOMER_CONTACT`
`supportedAccountDomiciles`	Provide country codes (in ISO 3166 alpha 2 -character format).
`appWebsiteURI`	Provide a URL to the application’s informational webpage, reachable from the Third Party Apps Search page.
`appSupportedProducts`	Provide a list of supported product lines for the application, reachable from the Third Party Apps Search page.
`appMessage`	Provide freeform text to display a message from the application to the end-user on the consent screen. This field is optional as of June 2026 release.
`reason`	Provide a reason for the requested action, such as “New record”, or “Updated redirect URL”.
`_version`	Provide the version. It must match the configured version in FDX services. It is set to 5.0 as of October 14, 2026.

3. Onboard to production

After you've completed testing in UAT, repeat the onboarding process for the production environment. Submit the required configuration files to create your production partner and application records. You can also use the onboarding templates to:

Register new applications
Modify existing applications
Deactivate unused applications

4. Configure connectivity and authentication

Before you can obtain user consent or exchange tokens, make sure your application can connect to the appropriate environment and authenticate with Business Direct Connect.

Authentication and security

Business Direct Connect APIs use OAuth 2.0 with certificate-based client assertion for authentication.

To authenticate, sign a JSON Web Token (JWT) with your private key and include it when requesting access tokens. This standards-based approach lets you authenticate securely without using client secrets.

To support this authentication model, you'll need:

A registered application and client ID.
A certificate or JWKS URI registered during onboarding.
A private key associated with the registered certificate.
A signed JWT client assertion.

You'll use these credentials during token exchange and token refresh operations.

Production and UAT URLs

This table describes the URLs and endpoints used for connectivity and API operations in both UAT (pre-production) and production environments:

Production and UAT URLs
URL type	UAT	Production
Authorization	`https://consent-uat.jpmorgan.com/app`	`https://consent.jpmorgan.com/app`
Access token issuance	`https://login.test.jpmorgan.com/h2w-api/oauth2/token`	`https://login.jpmorgan.com/h2w-api/oauth2/token`
Access token reissuance using refresh token	`https://login.test.jpmorgan.com/h2w-api/oauth2/token`	`https://login.jpmorgan.com/h2w-api/oauth2/token`
Revoke token	`https://login.test.jpmorgan.com/h2w-api/oauth2/token/revoke`	`https://login.jpmorgan.com/h2w-api/oauth2/token/revoke`
Business Direct Connect Data API	`https://api-test.payments.jpmorgan.com` (`Header`, `Authorization`, `x-fapi-interaction-id: <UUID>`)	`https://api.payments.jpmorgan.com/fdx/v6` (`Header, Authorization :<Auth token string>`, `x-fapi-interaction-id: <UUID>`)
Digital banking	`https://digital-banking-uat.jpmorgan.com/app`	`https://digital-banking.jpmorgan.com/app`
Consent management	`https://digital-banking-uat.jpmorgan.com/app/settings/integrations/business-direct-connect`	`https://digital-banking.jpmorgan.com/app/settings/integrations/business-direct-connect`

Common Data API headers

Include the following headers when invoking Business Direct Connect Data API endpoints.

Include the following headers when invoking Business Direct Connect Data API endpoints.
Header	Required	Description
`x-fapi-interaction-id`	Yes	Unique identifier for the interaction. Provide an Internet Engineering Task Force Request for Comments 4122 universally unique identifier (UUID).
`FDX-API-Client-Public-Key`	Optional	Public key the data provider can use to encrypt sensitive response data, such as an account number.
`FDX-API-Data-Provider-Id`	Optional	Identifies the financial institution that should respond to the request. You may omit this header when the API host doesn't require a data provider identifier.
`FDX-API-Data-Recipient-Id`	Optional	Identifies the data recipient making the request. You may omit this header when the data provider doesn't require a data recipient identifier.
`Fdx-Api-Actor-Type`	Optional	Identifies the API actor type. Business Direct Connect supports only `BATCH` operations.

Invoke J.P. Morgan Business Direct Connect APIs

After you obtain an access token, you can call J.P. Morgan Business Direct Connect Data API endpoints to retrieve:

Account information
Account details
Account transactions
Account statements
Payment network information
Account contact information

Include the required headers in each request and use the appropriate endpoint for your selected environment.

Working with responses

Pagination

Pagination behavior varies by endpoint:

For accounts and statements, use either offset or pageKey to retrieve paginated results. Don't include both parameters in the same request.
For transactions, follow the next link returned in the response to retrieve the next page. The transactions endpoint doesn't support offset or pageKey and returns a maximum of 100 transactions per page.
Pagination for payment network information is deprecated in Financial Data Exchange (FDX) version 6.5.

Date filtering

Use date or time parameters to retrieve transactions and statements for a specific period:

Use startDate and endDate for dates in YYYY-MM-DD format.
Use startTime and endTime for values in International Organization for Standardization (ISO) 8601 format.

For transaction requests, include either startDate or startTime. If you omit the corresponding end parameter, the request defaults to the previous day.

For statement requests, the date range defaults to the current month when you don't provide a date or time range.

Attention

Don't combine the date parameter pair with the time parameter pair in the same request.

Statement retrieval limitations

When you retrieve statements:

The requested date range can't exceed three years.
The start date can't be earlier than three years before the request date.
A statement with more than 400 pages isn't supported.
For an unsupported large statement, the response returns TOOLARGE_DO_NOT_DOWNLOAD in both the status and statementId fields and doesn't return a statement download link.

Payment network information

Retrieve payment network information for an account, including bank identifiers, account identifiers, identifier types, and supported payment network types. The response provides information required to execute a payment transaction against the account.

An account identifier can be an ACCOUNT_NUMBER or a TOKENIZED_ACCOUNT_NUMBER. An unmasked account number is sensitive data and should only be exchanged when encrypted.

To obtain user consent, construct the authorization URL using the appropriate environment endpoints.

Obtain User Consent
Environment	URI
UAT	`https://consent-uat.jpmorgan.com/app?client_id=<client_id>&redirect_uri=<redirect_uri>&state=<state>&response_type=code&code_challenge=<code-generated-by-partner>&code_challenge_method=S256&scope= jpmc:uri:uat:payments:fdx:access`
Production	`https://consent.jpmorgan.com/app?client_id=<client_id>&redirect_uri=<redirect_uri>&state=<state>&response_type=code&code_challenge=<code-generated-by-partner>&code_challenge_method=S256&scope= jpmc:uri:prod:payments:fdx:access`

If the authorization URI is well formed and query parameters are valid, the user logs in, authenticates, and selects the accounts to share. After the user consents, the system sends the authorization code to the redirect URL:

<redirect-uri>?client_id=<client id>&code=<auth_code>&iss=<issuer>&state=<state>&traceId=<Trace id>

Authorization flow

User signs in
User selects accounts
User grants consent
Authorization code is returned

Authorization URL parameters

The authorization URL parameters table describes the parameters required to construct the authorization URL for user consent. It specifies which fields are mandatory and provides a brief description of each field.

Authorization URL parameters
Field name	Mandatory	Description
`client_id`	Yes	Client identifier provided during onboarding.
`redirect_uri`	Yes	URL to which the user is redirected after consent is completed. Validation: The `redirect_uri` must be the one provided during onboarding
`state`	No	A random string by the application.
`response_type`	Yes	Specify code to request an authorization code.
`code_challenge`	Yes	Temporary secret; `base64URL` encoded `SHA256` hash. Must be 43–128 characters.
`code_challenge_method`	Yes	Specify `S256`
`scope`	Yes	UAT: `jpmc:uri:uat:payments:fdx:access` Production: `jpmc:uri:prod:payments:fdx:access`

6. Exchange authorization codes for tokens

Client assertion token generation

This flow uses a signed JSON web Token (JWT) to request an OAuth access token by sending a request to the token endpoint. Use these steps to create a client assertion token:

Fetch the private key and certificate
1. Obtain the private key and the corresponding certificate for the application (client).
2. Refer to the certificate generation section for instructions on creating the certificate.
Create the JWT
1. Construct a JWT with the header example parameters:

Header example

Json

{
  "kid": "<Short identifier for the certificate; generate the SHA-1 thumbprint>",
  "typ": "JWT",
  "alg": "RS256"
}

Payload example

Json

{
  "exp": "<Expiration time in Unix time>",
  "iat": "<Issued at time in Unix time>",
  "aud": "https://login.test.jpmorgan.com/h2w-api/oauth2/token",
  "iss": "<client_id>",
  "sub": "<client_id>",
  "nbf": "<Not before time in Unix time>"
}

3. Sign the JWT with the application's private key and the self-signed certificate using the RS256 algorithm.

Example of an assertion token

eyJraWQiOiJDQkVtYmVkZGVkQmFua2luZyIsInBpLmF0bSI6IjdpOW8iLCJhbGciOiJSUzI1NiJ9.eyJpYXQiOjE3MjEzMzk0NDgsImV4cCI6MTcyMTM0MTI0OCwiYXVkIjoiaHR0cHM6Ly9wZi5zaXQuYXV0aGUuZGV2LmF3cy5qcG1jaGFzZS5uZXQiLCJpc3MiOiJDX0pQTUNfMTE0MzU1X0lOVFVJVDk4LVFVSUNLQk9PS1MxMDZfU0lUXzAwMDczIiwic3ViIjoiQ19KUE1DXzExNDM1NV9JTlRVSVQ5OC1RVUlDS0JPT0tTMTA2X1NJVF8wMDA3MyJ9.X71QFuTGa4_qAmy_jrehWRD98EWoT_RUOYX27m5X4Hy10HtD_1TUl6EysXtJVLF3DdNST6BRnohXI0L5JgLGhdAkR1WKOJBspAIUUttWj6_ref7wnOvQZY0o2KL_4IPL3np-0WlLCkksWJHm66OKAjOECJg1pYxSnH5byaCzgK0NAaEBSIyN_-nS_2Aaux2OQSXtyqcCKFtFYsg4HAz2AwtFxyokWfYLxxWYG9X6o3h9eV3BJBh8066Y65h99aUtaURWQbtwnWLxFQ_iHI5mvwqtWXwuptR8NVL6VsB6ahX90Leu7n-78U7TPThdsYkrnaFw2PsAAnnOefu85C_O7Q

Exchange authorization code for access, refresh, and ID tokens

Send a request to the token endpoint.

<token endpoint URL>?client_id:<CLIENT_ID>&grant_type=authorization_code&code=<code>&code_verifier=<code_verifier>&redirect_uri=<https://redirect_uri>&client_assertion=<client_assertion>&client_assertion_type=<client_assertion_type>

Header: Content-Type: application/x-www-form-urlencoded'

Token exchange parameters

This table describes the parameters required when exchanging an authorization token for access, refresh, and ID tokens. Each parameter must be included in the request to the token endpoint.

Token exchange parameters table
Field name	Description
`client_id`	Client ID provided by us during onboarding.
`grant_type`	Set the grant type to `authorization_code`.
`code`	Authorization code received from the consent flow.
`client_assertion`	The client assertion is a JWT token signed with the application-specific private key.
`client_assertion_type`	The client assertion type must be `urn:ietf:params:oauth:client-assertion-type:jwt-bearer`.
`redirect_uri`	Redirect URI provided during onboarding.
`code_verifier`	Randomly generated string, for example: sX2yD5hJD9a5xTwclSUZVhxF3j8VaV38Yu6NPqWzjYo.

Sample response

The response returns the access token as shown in the sample response:

Json

{
  "access_token": "eyJhbGciOiJFUzUxMiIsImtpZCI6ImUxMWQzMWU0LTdjODctNDdhNi1hOGJlLTIxMjIxZGUzZmJiMSIsInR5cCI6IkpXVCJ9.eyJhYWwiOjEsImF1ZCI6IkpQTVNNQVJUQUNDT1VOVFNJVC1KUE1TTUFSVEFDQ09VTlRTSVQiLCJhdWRpdFRyYWNraW5nSWQiOiIxYmFmNmY4My05MjNlLTQ5N2MtYmRkZS1kMDIxYjgwNTQ3MDgtNDY0MjM5IiwiYXV0aEdyYW50SWQiOiJCYjRxd29VZ2J3bmk3UlZteTgwZHV4YW4yclUiLCJhdXRoX2xldmVsIjowLCJhdXRoX3RpbWUiOjE3NTc0MzUyMjUsImNsaWVudF9pZCI6IkpQTVNNQVJUQUNDT1VOVFNJVC1KUE1TTUFSVEFDQ09VTlRTSVQiLCJjdHMiOiJPQVVUSDJfU1RBVEVMRVNTX0dSQU5UIiwiY3R4Ijp7ImVtYWlsIjoiYXNob2trdW1hci5zb2xhaXJhamErRkRYU0ExQGNoYXNlLmNvbSIsImZhbWlseV9uYW1lIjoiU29sYWlyYWphIiwiZ2l2ZW5fbmFtZSI6IkFzaG9rIiwibmFtZSI6IkFzaG9rIFNvbGFpcmFqYSIsInBob25lTnVtYmVyIjoiKzE4MDE4NjQ2MzEwIiwicm9sZXMiOlsiRENCX0FDQ09VTlRfVklTSUJJTElUWSIsIkRDQl9BQ0hfUFJPVEVDVElPTiIsIkRDQl9BRE1JTiIsIkRDQl9BTEVSVFNfTk9USUZJQ0FUSU9OUyIsIkRDQl9DSEVDS19QUk9URUNUSU9OIiwiRENCX0xPQU4iLCJEQ0JfUkVQT1JUSU5HIiwiRENCX1NUQVRFTUVOVFMiLCJEQ0JfV0lSRV9UUk5TIiwiTVlET0NTIiwiU0NIRExSIiwiVE5DIl0sInV1aWQiOiI5MDkwMDU5Mi03ZjUwLTRmNDYtOThjMS1mMjFhNDdiYTNjN2MifSwiZXhwIjoxNzU3NDM2MjA2LCJleHBpcmVzX2luIjo5MDAsImdyYW50X3R5cGUiOiJhdXRob3JpemF0aW9uX2NvZGUiLCJpYXQiOjE3NTc0MzUzMDYsImlzcyI6Imh0dHBzOi8vbG9naW4udGVzdC5qcG1vcmdhbi5jb20vaDJ3LWFwaSIsImp0aSI6Ikc0UlZUVDFUOTZoM1RKM2kxdUNQbnpqbUZUUSIsIm5iZiI6MTc1NzQzNTMwNiwicmVhbG0iOiIvYWxwaGEiLCJyb2xlcyI6bnVsbCwic2NvcGUiOiJqcG1jOnVyaTpzaXQ6cGF5bWVudHM6ZmR4OmFjY2VzcyIsInN1YiI6ImNkMWI1NzJkLWVhMTYtNGVkNS04MmI5LWZjZjg0ZmFhZDExYyIsInN1Ym5hbWUiOiJjZDFiNTcyZC1lYTE2LTRlZDUtODJiOS1mY2Y4NGZhYWQxMWMiLCJ0b2tlbk5hbWUiOiJhY2Nlc3NfdG9rZW4iLCJ0b2tlbl90eXBlIjoiQmVhcmVyIiwidXNlcm5hbWUiOiIifQ.Ac8eIDCYwaZZ-Bq7BtAvbVkbp8yfaorPZCWHQXAB1-GgbfyDwiwJ0WkRiwGpxyc5tkcOJWqli-RwGL6ejPsmkUZoAT2k-cPst0M-XrmW6wrr9dB2sgKZgV2jHtGMKl6DBdrYXM_AqldYE9L67G9U-13BFLgUKp41P9Fva8aMxAO-z_Zg",
  "refresh_token": "eyJhbGciOiJFUzUxMiIsImtpZCI6ImUxMWQzMWU0LTdjODctNDdhNi1hOGJlLTIxMjIxZGUzZmJiMSIsInR5cCI6IkpXVCJ9.eyJhYWwiOjEsImFjciI6IjAiLCJhdF9oYXNoIjoiamdUbExuVzZRaTBmbURkclgxNi1pZyIsImF1ZCI6IkpQTVNNQVJUQUNDT1VOVFNJVC1KUE1TTUFSVEFDQ09VTlRTSVQiLCJhdWRpdFRyYWNraW5nSWQiOiIxYmFmNmY4My05MjNlLTQ5N2MtYmRkZS1kMDIxYjgwNTQ3MDgtNDY0MjQwIiwiYXV0aEdyYW50SWQiOiJCYjRxd29VZ2J3bmk3UlZteTgwZHV4YW4yclUiLCJhdXRoX2xldmVsIjowLCJhdXRoX3RpbWUiOjE3NTc0MzUyMjUsImNsaWVudF9pZCI6IkpQTVNNQVJUQUNDT1VOVFNJVC1KUE1TTUFSVEFDQ09VTlRTSVQiLCJjdHMiOiJPQVVUSDJfU1RBVEVMRVNTX0dSQU5UIiwiZXhwIjoxNzg4OTcxMzA2LCJleHBpcmVzX2luIjozMTUzNjAwMCwiZ3JhbnRfdHlwZSI6ImF1dGhvcml6YXRpb25fY29kZSIsImlhdCI6MTc1NzQzNTMwNiwiaXNzIjoiaHR0cHM6Ly9sb2dpbi50ZXN0LmpwbW9yZ2FuLmNvbS9oMnctYXBpIiwianRpIjoiUkhXM2NzYTgwOFRIUGU5Q0VQYnJQQjVDb0lBIiwibmJmIjoxNzU3NDM1MzA2LCJvcHMiOiJyZVpPbWUrcG1sVEJNdXdPOFJmU2swZENOakI4K3FQZ1pHRzYxbE1ObjlZPSIsInJlYWxtIjoiL2FscGhhIiwicm9sZXMiOm51bGwsInNjb3BlIjoianBtYzp1cmk6c2l0OnBheW1lbnRzOmZkeDphY2Nlc3MiLCJzaWQiOiJRQis2R1diR0lEcG9jdHJsQXBzampXbjNEVkNmaWQyU000NGpyaHh3WmkwPSIsInN1YiI6ImNkMWI1NzJkLWVhMTYtNGVkNS04MmI5LWZjZjg0ZmFhZDExYyIsInN1Ym5hbWUiOiJjZDFiNTcyZC1lYTE2LTRlZDUtODJiOS1mY2Y4NGZhYWQxMWMiLCJ0b2tlbk5hbWUiOiJyZWZyZXNoX3Rva2VuIiwidG9rZW5fdHlwZSI6IkJlYXJlciIsInVzZXJuYW1lIjoiIn0.AJxYikoZvfdjv5a6RBm-AuziahpwbuhwR3l3cbWnpvDbokS821gevoCDSJVE7M-otdNr19SrbSeEyxBIu8KJcZR0AIsfsqPMErCKPzLmtz1PbQAjc6zTCV-cjn4j2dM7s2Hyg-3MOZmT1KTVym-UN-lLgoDhv8gVbuAR5eKykGuvEspz",
  "id_token": "eyJhbGciOiJFUzUxMiIsImtpZCI6ImUxMWQzMWU0LTdjODctNDdhNi1hOGJlLTIxMjIxZGUzZmJiMSIsInR5cCI6IkpXVCJ9.eyJBQUwxIjoiZXlKMGVYQWlPaUpLVjFRaUxDSnJhV1FpT2lKbE1URmtNekZsTkMwM1l6ZzNMVFEzWVRZdFlUaGlaUzB5TVRJeU1XUmxNMlppWWpFaUxDSmhiR2NpT2lKRlV6VXhNaUo5LmV5SnpkV0lpT2lKalpERmlOVGN5WkMxbFlURTJMVFJsWkRVdE9ESmlPUzFtWTJZNE5HWmhZV1F4TVdNaUxDSnBZWFFpT2pFM05UYzBNelV5TWpRc0ltbHpjeUk2SWxObGJuUnllU0lzSWtGQlRDSTZNU3dpWlhod0lqb3hOelUzTkRZME16STBmUS5BT254UnpHZUVfXzNUMHZ5dHlscGM1OXFwMHV3Nk5pT2tXNFNaT1FzMGlKOXFKSDhJaWdNZUh3bUlxTVdibmxBRkdIazZrX0pxU0VzM3Mtd00wMWxYcWdFQVd2SEJ5Y1I5TlpHSHRveEQ0VG5IYlR3bldhYm1DWnpvdmZxUjFLNlBScl9RYV9GN2RtOTc1S3ROQlpROGVKQ3dsRnQtTDhfMW90dnI2ZHdLejZWMURBaiIsImFhbCI6MSwiYWNyIjoiMCIsImF0X2hhc2giOiJqZ1RsTG5XNlFpMGZtRGRyWDE2LWlnIiwiYXVkIjoiSlBNU01BUlRBQ0NPVU5UU0lULUpQTVNNQVJUQUNDT1VOVFNJVCIsImF1ZGl0VHJhY2tpbmdJZCI6IjFiYWY2ZjgzLTkyM2UtNDk3Yy1iZGRlLWQwMjFiODA1NDcwOC00NjQyNDEiLCJhdXRoX3RpbWUiOjE3NTc0MzUyMjUsImF6cCI6IkpQTVNNQVJUQUNDT1VOVFNJVC1KUE1TTUFSVEFDQ09VTlRTSVQiLCJjX2hhc2giOiIyMFJXalh4WlpjWVhTTHVNc3hvUy1BIiwiY2xpZW50X2lkIjoiSlBNU01BUlRBQ0NPVU5UU0lULUpQTVNNQVJUQUNDT1VOVFNJVCIsImVtYWlsIjoiYXNob2trdW1hci5zb2xhaXJhamErRkRYU0ExQGNoYXNlLmNvbSIsImV4cCI6MTc1NzQzNjIwNiwiZXhwaXJlc19pbiI6OTAwLCJmYW1pbHlfbmFtZSI6IlNvbGFpcmFqYSIsImdpdmVuX25hbWUiOiJBc2hvayIsImdyYW50X3R5cGUiOiJhdXRob3JpemF0aW9uX2NvZGUiLCJpYXQiOjE3NTc0MzUzMDYsImlzcyI6Imh0dHBzOi8vbG9naW4udGVzdC5qcG1vcmdhbi5jb20vaDJ3LWFwaSIsIm5hbWUiOiJBc2hvayBTb2xhaXJhamEiLCJyZWFsbSI6Ii9hbHBoYSIsInJvbGVzIjpudWxsLCJzX2hhc2giOiJGX0ZsMWFXNmFWOG53Q09vT3FLelJnIiwic2NvcGUiOiJqcG1jOnVyaTpzaXQ6cGF5bWVudHM6ZmR4OmFjY2VzcyIsInNpZCI6IlFCKzZHV2JHSURwb2N0cmxBcHNqalduM0RWQ2ZpZDJTTTQ0anJoeHdaaTA9Iiwic3ViIjoiY2QxYjU3MmQtZWExNi00ZWQ1LTgyYjktZmNmODRmYWFkMTFjIiwic3VibmFtZSI6ImNkMWI1NzJkLWVhMTYtNGVkNS04MmI5LWZjZjg0ZmFhZDExYyIsInRva2VuTmFtZSI6ImlkX3Rva2VuIiwidG9rZW5UeXBlIjoiSldUVG9rZW4iLCJ1c2VybmFtZSI6IiJ9.AR3W2vPjdVaVxRz8oGxycY8n3Yk3B-k7dkQolINID_iLOSHvlQIsvfIfOQ6txwR8nvgHcdkWIuWHcQI12LpQLcI-AKCZ2zYcHDovViisu3gf0KAdlgykC2oep-JAeTyL-39UBk87DUExREJ2CeA6m6EfpkgCB8A4dJea5ZePRLwnLwSL",


  "scope": "jpmc:uri:uat:payments:fdx:access",
  "token_type": "Bearer",
  "expires_in": 3599
}

UAT environment example

Header example

Json

{
  "kid": "250c2fc267635b07169d0afe984b62a0f12382de",
  "alg": "RS256",
  "typ": "JWT"
}

Payload example

Json

{
  "nbf": 1757698700,
  "exp": 1757699000,
  "iat": 1757698700,
  "aud": "https://login.test.jpmorgan.com/h2w-api/oauth2/token",
  "iss": "client_id",
  "sub": "FINNEZ-MONEYSYNC"
}

Signature (encoded)

JPCq8ZRMywhMxEJf0B7UIr9XVNI7405csLymrG7ax0Qhypo-TzrlOViI-nZ_nvnZcZtR71_UEMCwsl4-UlYNZ20MBUZTA0rB7ypDK5g4DFsSxGQwAIJ00pb3-0LUt8poAdaKFWiPLT-mZmeIeBBpqiNGELRdW1-SxRRq2h_abJWRQ1uiRHz9k5RNXUIAtPaqn2b8Lal8tWvP-fftEjt1vM42yjMK1H2eksBfzxzGQ0qnN289C2Jc6QomxoAbm5kWcL9KsRBZwDIM6uJan56Zryaw1zx6pvy_ClkuWPCmh4OOWTjfL3DLiLbOtXMoW6sa4EBdsaDNblcemwQMeV_zXkw

Production environment example

Header example

Json

{
  "kid": "250c2fc267635b07169d0afe984b62a0f12382de",
  "alg": "RS256",
  "typ": "JWT"
}

Payload example

Json

{
  "kid": "250c2fc267635b07169d0afe984b62a0f12382de",
  "alg": "RS256",
  "typ": "JWT"
}

Signature (encoded)

JPCq8ZRMywhMxEJf0B7UIr9XVNI7405csLymrG7ax0Qhypo-TzrlOViI-nZ_nvnZcZtR71_UE

7. Manage token lifecycles

This section explains how to refresh and revoke tokens.

This table explains token lifecycles.
Token	Lifetime
Access token	15 minutes
Refresh token	1 year. The user must re-consent to renew.
Client Assertion	60 seconds

Refresh the access token

Send a request to the token endpoint.

<token endpoint URL>?client_id=<CLIENT_ID>&grant_type=<refresh_token>&refresh_token=<refresh token>&client_assertion=<client_assertion_token>&client_assertion_type=<client_assertion_type>&code_verifier=<code_verifier>

Header: Content-Type: application/x-www-form-urlencoded

Refresh token parameters

The refresh token parameters table describes the parameters required to refresh the access token using the refresh token:

Table-1
Field name	Description
`header`	Content-Type: `application/x-www-form-urlencoded`
`client_id`	Client ID provided by us during onboarding
`grant_type`	`refresh_token`
`refresh_token`	Refresh token example: daKDqweERo4utdbgVmXc2xY8Q7WpPadEFc8e3L8ZSy
`client_assertion`	Client assertion token
`client_assertion_type`	urn:`ietf:params:oauth:client-assertion-type:jwt-bearer`
`code_verifier`	Randomly generated string example: eyJhbGciOiJFUzUxMiIsImtpZ.

Revoke token

Send a request to the token revocation endpoint: https://login.test.jpmorgan.com/h2w-api/oauth2/token/revoke

Header: Content-Type: application/x-www-form-urlencoded'

Revoke refresh token parameters

The revoke refresh token parameters table describes the parameters required to revoke the access token:

Revoke the refresh token
Field name	Description
`client_id`	Client ID provided during onboarding.
`token`	Token to revoke.
`Client_assertion_type`	urn:`ietf:params:oauth:client-assertion-type:jwt-bearer`
`Client_assertion`	Client assertion token

Appendix

Naming the bank feed

When you configure or display the J.P. Morgan bank feed, use the following information. This feed is available only to J.P. Morgan Digital Banking clients and isn't supported for other J.P. Morgan platforms, such as JPM Access.

J.P. Morgan Business Direct Connect - Naming the bank feed
Site name	Site URL	Description
J.P. Morgan - Business Direct Connect (for J.P. Morgan Digital Banking)	https://digital-banking.jpmorgan.com	Use this bank feed to connect to J.P. Morgan Digital Banking accounts. This feed is available only to J.P. Morgan Digital Banking clients.

See the FAQs page for answers to common questions and issues encountered during integration.
Refer to the support page for support information and to report production issues.

Integration guide

Before you begin

Onboarding overview

1. Onboard your organization into the UAT environment

Partner registration

Modify an existing registration

Create a partner onboarding request

Partner onboarding template

Partner onboarding instructions

2. Onboard your application in the UAT environment

Application registration

Modify an existing application registration

Create an application onboarding request

Application onboarding template

3. Onboard to production

4. Configure connectivity and authentication

Authentication and security

Production and UAT URLs

Common Data API headers

Invoke J.P. Morgan Business Direct Connect APIs

Working with responses

Pagination

Date filtering

Statement retrieval limitations

Payment network information

5. Obtain user consent

Authorization flow

Authorization URL parameters

6. Exchange authorization codes for tokens

Client assertion token generation

Header example

Payload example

Example of an assertion token

Exchange authorization code for access, refresh, and ID tokens

Token exchange parameters

Sample response

UAT environment example

Header example

Payload example

Signature (encoded)

Production environment example

Header example

Payload example

Signature (encoded)

7. Manage token lifecycles

Refresh the access token

Refresh token parameters

Revoke token

Revoke refresh token parameters

Appendix

Naming the bank feed

Related