Akoya API v2.2 (September 6, 2023)

Earlier this summer we launched our new Statements product and added an alternative endpoint option for our Customers products. We’re continuing to improve and are happy to announce new resources and support to further support your integration on the Akoya network.

To help you find what you need and to add our new features, we’re also updating our documentation to be more user friendly. Keep reading to see all the new, exciting updates.

Akoya Management API

Akoya has introduced an API to allow you to create applications and request subscriptions to providers.

You’ll be able to get lists of providers on the network, details on all your apps filtered by Akoya, view application subscription status, and more.

The Management API has been available as a preview but is now more broadly available. Read more in the Management API Guide.

Updates to support FDX v5.3

Akoya anticipates adding support for FDX 5.3 in Q1 2024. However, we’ve been gradually adding improvements already. One such update is added support for debugMessage, when available, for error codes.

Partial response coverage

We’re continuing to improve error handling by implementing a 206 response. When supported by the provider, Akoya has added the ability to return partial responses when data requests are successful but includes an account with an error.

The following endpoints are capable of returning a partial response.

• /account-info

• /balances

• /accounts

What does this mean for me?

Right now, if there is an error with any account that should be in a response, you may receive an error or a timeout. Now, if you include 206 support, you will receive information from all accounts included in the request, either with the requested data or an account specific error.

For more, please see: Products overview

Interaction type header

Akoya now supports a new header based on the FDX v5.3 specification. The optional x-akoya-interaction-type header should be sent by you with all Akoya product calls to indicate if the request is part of a batch process or a real-time, end-user interaction. The header has been added to all Akoya product endpoints.

The x-akoya-interaction-type is optional but recommended with allowed values user or batch.

• user indicates a request is prompted by an end-user action.

• batch indicates the request is part of a batch process.

Why add the header?

This header allows Akoya to inform any provider which requires this information if a call was made because an end-user initiated an interaction and is awaiting the results or if it's part of an automated batch job. This allows traffic to be prioritized while maintaining the best possible experience for the end-user.

What does this mean for me, today?

This header will remain optional in Akoya’s v2 product APIs. However, we recommend implementing the header as a best practice. Until you are able to add this header, Akoya default the header value to batch.

Please note, the x-akoya-interaction-type header will not be required in Akoya API v2 but will be required in any future major version releases.

Please see the Headers guide for more details.