Headers

Akoya returns or accepts the following Akoya custom headers.

Interaction id

Unique to each request, Akoya returns an auto-generated interaction identifier in the header of each response. This id may be used for your own logging purposes and as a trace identifier for troubleshooting. When implementing your app, we recommend storing the x-akoya-interaction-id of each response. For more on how x-akoya-interaction-id is used for troubleshooting, see: Troubleshooting.

Interaction type

Akoya supports an optional header based on the FDX v5.3 specification. You should 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. The header is supported by all Akoya product endpoints.

The x-akoya-interaction-type has allowed values user or batch.

• user indicates the request is prompted by an end-user action.
• batch indicates the request is part of a batch process.

x-akoya-interaction-type 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.

🚧

Some providers will require this information.

Check the Data Recipient Hub to see if a provider you’re subscribed to will require this header. While x-akoya-interaction-type will remain optional in Akoya’s v2 product APIs, if a provider requires this header and it is not passed, Akoya will default the header value to batch.

📘

Next major release

While the next major release by Akoya is currently unplanned, the x-akoya-interaction-type header will be required in any future major version releases.