Welcome to Aura API Documentation
Welcome to Aura API !
Welcome to the API documentation for Aura! Here you will find comprehensive information about the endpoints and resources offered by our API.
At Aura, our API ethos is rooted in openness, flexibility, and empowerment. We recognize APIs as the bedrock of a connected and progressive financial services ecosystem, facilitating seamless integration and fostering innovation.
With a commitment to transparency and interoperability, we provide developers with clear and adaptable APIs that cater to diverse business needs. Our focus on developer-friendliness, comprehensive documentation, and robust security measures empowers developers to unleash their creativity and drive digital transformation within the financial services industry.
API Reference
In the API Explorer page, you will find comprehensive documentation for each endpoint and resource available in the API. This documentation provides detailed information about how to interact with the API and utilize its functionalities.
For each endpoint, the API documentation will typically include the following information:
Endpoint URL: The URL at which the endpoint can be accessed
HTTP Method: The HTTP method (e.g., GET, POST, PUT, DELETE) used to interact with the endpoint.
Parameters: Any required or optional parameters that need to be included in the request. These parameters can be sent as query parameters, request body, or headers.
Request Example: An example request that demonstrates how to structure the request, including any required parameters or headers.
Response Example: An example response that illustrates the structure and format of the response returned by the API.
Response Codes: The possible HTTP status codes that can be returned by the API, along with their meanings. These codes indicate the success or failure of the request.
Visit the API Explorer page to explore the available endpoints and resources. These are a sample set of APIs, feel free to contact us through our website, for more APIs to suit your business needs.
Authentication
Authentication to Aura API is using user account and key.
Provide your username and password directly via the Authorization header.
To ensure the username and password cannot be intercepted, all requests must use HTTPS.
HTTP Verbs
The following HTTP verbs are supported for interacting with the API:
GET : To retrieve a resource or a collection of resources
POST : To create a resource
PATCH : To modify an existing resource
PUT : To replace an existing resource
DELETE : To delete a resource
Payloads
The Aura API supports endpoints that accept and return payloads in application/json.
When making a POST, PUT, or PATCH request, it is essential to include the Content-Type header to specify the content type of the payload being sent.
Requests & Responses
API requests, also known as API calls, to the Aura API are used to identify the requester and specify the desired action or information to be retrieved.
To construct an API request, you need to combine the following elements:
The HTTP verb indicating the desired action (e.g.,
GET,POST,PUT,PATCH,DELETE).The full URI (Uniform Resource Identifier) specifying the resource or endpoint to interact with.
HTTP headers, including authentication headers, versioning headers, and headers specifying the content types of the payload if applicable.
The payload, which is the data being sent with the request (if required).
When making a request to the Aura API, the response will either contain an error response or a payload in the content type that the endpoint accepts.
Error Responses
An error response consists of the following fields:
errorCode : number - Always Present - A unique error code. For more information, see API Reference Page
errorSource : String - Sometimes Present - A human-readable message capturing unsatisfied constraints.
errorReason : String - Always Present - A human-readable message stating the general category of the failure.
Idempotency
Idempotent requests to the Aura API are guaranteed to be executed no more than once. This feature is enabled on request.
Working with financial transactions, it is important to ensure some requests are not repeated for any reason, which may result in data loss or accidental duplication. You may configure requests to be idempotent by providing an Idempotency-Key header and providing a unique UUID token for the request. This will guard against the possibility of error if a request must be retried.
When an idempotent request is processed, the status code and body of the response is associated with the idempotency key and stored in a cache. If the request is duplicated for any reason, the duplicate request will not be processed, and the response will be re-sent to the client.
Idempotent requests that fail at the server level, such validation failures, are not stored in the cache. Subsequent requests with the same idempotency key will be processed as if they were new, receiving the same 400 BAD REQUEST status code.
Idempotency keys expire after six hours in Aura API. After this time period, requests using duplicate keys will be treated as new requests.
Idempotency keys must use the v4 UUID format (32 hexadecimal digits, in an 8-4-4-4-12 arrangement, such as 01234567-9abc-def0-1234-56789abcdef0).
We recommend generating UUIDs programmatically or by using an online generator such as UUID Generator to ensure that all keys are valid V4 UUIDs.
Retry mechanisms must:
Use the same key for initial calls and retries.
Retry at a reasonable frequency so as not to overload the API.
Properly identify and handle error codes.
Pagination
The Aura API offers customizable pagination capabilities for GET requests. It is highly recommended to utilize pagination filtering when dealing with requests that might return a large number of records, as this significantly improves response times.
By default, pagination is disabled and needs to be specified in each request. Two query parameters are available: "start" and "totalcount".
The "start" parameter indicates the starting row number. For the first request, set it as 1, and for subsequent requests, adjust it based on the total number of records received in the previous response. For example, if the first request fetched 100 records and you want to retrieve the next set, set the "start" value as 101.
The "totalcount" parameter specifies the maximum number of records to be included in the response. In the first request, the Aura API provides the total number of records available for the query. Based on this information, you can tailor the "start" and "totalcount" query parameters for subsequent requests.
Audit Trail
The Audit Trail feature in the Aura Core Banking system tracks all activities performed via the UI or API.
When the Audit Trail feature is enabled, you must provide a User-Agent header for all requests to any endpoint. Otherwise, the request will fail with the error message "The user agent cannot be null when the Audit Trail feature is enabled."
Note that if you are using a REST client like Postman or cURL, this header is usually provided automatically. However, if you generate a request to the API manually, you need to include the header yourself.
The User-Agent header provides information about the browser, operating system, and the client library or tool issuing the request. It is commonly used for debugging purposes.
Getting Started with APIs
New to Aura APIs? Get yourself a head-start through this general introduction before getting into the details of various APIs.
All Business APIs in Aura are directed towards a certain business goal and hence are with reference to a Client. A Client is created based on a natural or artificial person. All natural persons will be created as Person record and artificial persons will be created as Organisation record. When a Person or Organisation starts business interactions with the Bank / Financial Institution, Personal or Corporate Client record will be created.
Example: Person A is an authorized signatory of Company XYZ. An account has to be created for XYZ. In Aura, it will proceed as follows: Create Organisation XYZ, Person A, Corporate Client XYZ and Account
Along with the Client, certain other parameters like Branch, Currency and Service Delivery Channel are also required for most of the actions in Aura.
There are different Product Types in Aura – Client Account, Term Deposit, Mortgage&Loan, Card Account – to name a few. Under each of these Product Types, based on the Business Requirements, various Products can be set up by the Product Owner. Along with Pricing (interest and charges), the entire life cycle and accounting parameters are defined at the Product. Accounts are created under the required Product for the Clients; and these move through various stages in their life-cycle and appropriate accounting entries are passed based on the Product definitions till their logical closure.
Many parameters in Aura are maintainable parameters. The Product Owner would be aware of such values maintained for any implementation. It is very important that you should be in touch with the Product Owner to provide the appropriate valid parameters in the API request.
Example: Address Type is a maintainable parameter in Aura. So, you could have different Address Types like Registered Address, Communication Address, Home Address, Work Address, etc., Based on the business requirements, the Product Owner would decide and maintain these values in Aura.
Most configurable parameters in Aura have a Business Id and the UUID. In many cases, you should be able to provide either the Business Id or the UUID for such parameters. As a general rule, if both Business Id and UUID are provided in the request, the UUID will take precedence for record creation
Many parameters in Aura have a pre-defined list of valid values. These are indicated clearly in the Description. Please ensure that the provided value matches exactly with the list for that tag.
All the tags in the API structure are given in alphabetic order, irrespective of whether they are mandatory, optional or conditional. This makes it easy to search for tags that are mentioned in the Description on which a tag may be conditional. On the other hand, since the tags are in alphabetical order they are not logically grouped. Hence it is advisable to go through all the tags in the API.
Conditionally mandatory tags are clearly indicated in the first line of the Description as follows: {Conditional}. The tag itself is indicated as non-mandatory (Required = false); but, it could be conditionally mandatory. Please read through the Description carefully to identify if it is so. The Description clearly states the other tag based on which this tag is mandatory.
Example: In Create Person, AddressType is an optional field. If AddressType is provided, address1 is a conditionally mandatory field.
The API structure defines the tags AddressType and AdressTypeUUID as non-mandatory (Required = false). The first line in the Description for Address1 mentions {Conditional}. The description also clearly states Mandatory if AddressType or AddressTypeUUID is provided clearly indicating that Address1 is mandatory if AddressType or AddressTypeUUID has any value in the API request.
To summarize, get yourself the header parameters, credentials for the correct environment, speak to your product owner to understand configured parameters and allowed values and follow the description in the API and you are good to go.
Support & Community
We are committed to providing excellent support to our developers and fostering an active community. If you have any questions, issues, or suggestions related to the API, feel free to reach out to our support team. You can also join our developer community to connect with other developers, share your experiences, and collaborate on projects.