📚 Glossary

For an explanation of Akoya-specific parameters, please refer to the Environment parameters section.

Akoya

Akoya Data Access Network (DAN): Managed platform leveraging industry standards for data providers and data recipients to empower the consumers with a secure and transparent way to share data.
Data Access API: The Data Access API allows recipients to request consumer-permissioned data to flow from a provider through the DAN. Based on the FDX specification, it includes accounts and transactions endpoints.
Data Recipient Hub: Our developer portal. This is where you manage your API credentials and register your redirect URI(s).
Mikomo Financial: Akoya’s mock data provider, Mikomo, can be used in Sandbox to test against representative responses from all data providers live on the DAN. See Introduction to Mikomo and the sandbox for more details.
Permission API: The Akoya Permission API allows a data provider to create or support a permission dashboard for its end-users.
Sandbox: A dedicated test environment, Sandbox, allows recipients to make real calls to Akoya token and data access endpoints. The only data provider available in Sandbox is Mikomo.
x-akoya-interaction-id: An auto-generated interaction identifier, the x-akoya-interaction-id is returned in the header of each call, unique to each request, and used as a trace ID for troubleshooting.
x-akoya-interaction-type: Supported by all Akoya product endpoints, this is a header used to indicate if the request is part of a batch process or a real-time, end-user interaction. Allowed values are user or batch. For more information, please see headers.

Data access

Client ID: Public identifier of an app.
Client secret: Private identifier of an app used during authentication of an API.
Consumer: An individual or representative acting on behalf of an individual with ownership rights to the data and transactional capabilities at a data provider.
Data aggregator: Entities that obtain consumer financial data from data providers.
Data provider: A financial institution, like a bank, investment firm, or other organization which provides financial services to consumers.
Data recipient: A third-party, like a data aggregator or fintech company, which processes financial data on behalf a consumer.
Financial Data Exchange (FDX): A nonprofit dedicated to unifying the financial industry around a common, interoperable, royalty-free standard for the secure access of consumer and business financial data. For more information, see our Introduction to FDX.
Screen scraping: When a customer gives their user name and password to a third-party, usually a data aggregator, to sign in as that consumer, and extract information to populate its service. With these credentials, a third-party has the same access to an account as the customer themselves. This means that customers lack control over the scope or even duration of access they give to a third-party.

Authorization, authentication, and tokens

Authentication: Process of obtaining credentials from a user to verify the user's identity.
Authorization: Process of granting access rights to an authenticated entity.
Authorization code: Temporary code that the data recipient (data aggregator or fintech company) will exchange for an ID token. In Akoya's testing environment, the authorization code is valid for 5 minutes.
ID token: An OIDC security token which contains the user’s authentication information in a JSON Web Token (JWT). JWT is a standardized, validated and/or encrypted container format used to securely transfer data between two parties. For more information, see our Token explainer. In Akoya’s testing environment, the ID token is valid for 30 minutes.
OAuth: An open standard for token-based authorization protocol on the internet. It enables apps to obtain limited access to a user’s data using a token instead of a user’s password. The token grants access to just the information a consumer has authorized for a specific app.
OpenID Connect (OIDC): An identity layer built on top of the OAuth 2.0 protocol. It defines a sign-in flow that enables a client application to authenticate a user and to obtain information (or "claims") about that user, such as the user name and email. User identity information is encoded in a secure JSON Web Token (JWT).
Redirect URI: The location (typically in your application) where users are sent after they authenticate successfully with their financial institutions.
Refresh token: A token used to get a new set of refresh and ID tokens when the ID token expires or becomes invalid.

API terminology

API: Acronym for Application Programming Interface. APIs let applications (and devices) seamlessly connect and communicate securely.
cURL: Tool to transfer data from or to a server using one of the supported protocols.
Endpoint: Specifies where resources are located that can be accessed by third party software. Usually access is via a URI to which HTTP requests are posted and from which the response is expected.
Header: A user defined HTTP header which carries information about a request in a REST call.
HTTP Verbs: The four basic HTTP verbs Akoya uses in requests to interact with resources in a REST system:
1. GET — retrieve a specific resource (by id) or a collection of resources
2. POST — create a new resource
3. PUT — update a specific resource (by id)
4. DELETE — remove a specific resource by id
REST (or Representational State Transfer): An architectural style for providing standards between computer systems on the web, making it easier for systems to communicate with each other. In brief, in the REST architectural style, data and functionality are considered resources and are accessed using Uniform Resource Identifiers (URIs).
Uniform Resource Identifier (URI): A string of characters that refers to a resource. The most common are URLs, which identify the resource by giving its location on the web.

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.