Requirements & best practices

We have a number of implementation requirements to ensure the security of our network and your end-users' financial data.

🚧

Please review these requirements before continuing!

Requirements

• A consent UX in your app

  • Your end-user should consent to the access and use of their data from the original data provider. The Akoya consent flow leverages OAuth 2.0 authorization. For more information, see:

    • Authorization request

    • Authorization code grant type

    • Refresh token grant type

• OIDC token use with secure, encrypted storage

• Redirect URI(s)

  • The callback resource in your application where Akoya will send the end-user and authorization code after successful authentication

• Secure, encrypted storage for your app’s client_id, client_secret and all tokens

  • The client_secret should NEVER be hard-coded into your application's source code.

Best practices

• One Hub account. Your company should maintain one Data Recipient Hub team account. The first team member to join the Hub should send invitations to the remaining members of the team. See: Data Recipient Hub v5.

• Token revocation. Provide a link for the end-user to revoke permission for use of their provider's accounts.

• Pagination. Build a pagination component into your app, allowing it to receive one page at a time.

• Provider guidelines. Adhere to implementation differences required by some data providers. These guidelines, and other integration considerations, are documented by provider in the Data Recipient Hub.

• Outages. When major service disruptions occur that impact the network, such as an event that causes you to invalidate all tokens or forces re-authentication, please notify Akoya. To notify Akoya, sign into the Data Recipient Hub and visit the Support Center.

• Errors.

  • For 500-level HTTP errors, we recommend implementing three (3) retries to help your app deal with short-lived, transient failures. The waiting time between retries should increase exponentially with each retry attempt.

• Versioning. Akoya limits breaking changes to major API versions. To reduce the need for large, breaking-change updates, Akoya will continue to improve its products by releasing minor updates on a continual basis. These minor updates are non-breaking, backward-compatible improvements. When migrating to Akoya API v2, please plan for these minor version updates and implement in a way to allow for these non-breaking changes. See: Versioning.

• Requests.

  • Send the x-akoya-interaction-type header with all Akoya product calls to indicate if the request is part of a batch process or a real-time, end-user interaction. See: Headers.
  • When using a batch or bulk process, we recommend implementing your app to handle HTTP status 429, error code 1207. If receiving this response, send bulk requests at a slower rate.

• Responses.

  • Track the header x-akoya-interaction-id returned with each Akoya API request. See: Headers.
  • Your app should handle 206 HTTP Partial Responses.

FDX

Akoya API v2 is based on Financial Data Exchange (FDX) specifications (learn more about FDX here). The following FDX guidance is recommended while using Akoya API v2:

• Utilize the FDX API, security, and user experience specifications.

• Follow FDX version recommendations for API deprecation.

Recipients need not be members of FDX to integrate with the Akoya Data Access Network; however, FDX provides a variety of membership options. It also provides fee-free access to API specifications by accepting the intellectual property agreement.

Need help?

Check out our Developer Community, or visit the Support Center in the Data Recipient Hub.

Looking for provider nuance documentation?

All provider nuance documentation is available in the Data providers section in the Data Recipient Hub.

Still stuck?

For all production issues, submit a support ticket through the Data Recipient Hub. Our support team is standing by 24/7. Questions and non-production issues will be answered during business hours.