API Versioning is a process to performing an impact analysis of the proposed change in API and decide on the version number.The NBFC-AA APIs follow Semantic API Versioning which has the format of X.Y.Z where X indicates the Major version, Y reflects the Minor version and Z denotes the Patch version.
API Governance ensures that a standard process is applied to release of new changes in the APIs
API Version is applied to the catalog of APIs and not to an individual API. For NBFC-AA ecosystem participants, the following three API catalogs have been published:
•Account Aggregator (AA) APIs
•Financial Information Provider (FIP) APIs
•Financial Information User (FIU) APIs
A major version is released whenever there is a Breaking change. That is, the changes introduced in the latest API version are not compatible with the earlier versions.
Deprecation and decommission of earlier API versions is required to ensure smooth adoption of major version.
Any change in the APIs is published on the ReBIT website. Also, major changes are announced on the social media pages of ReBIT i.e., LinkedIn & Twitter.
A deprecated API is not recommended to use since there is a new version available for that API. However, the API will continue to function till the decommission date.
https://api.rebit.org.in/faqDecommissioning means that the API will no longer be available after the pre-decided decommission date. The API provider should be ready with the new version before decommission date and API consumers should only use the new version post decommission date.
https://api.rebit.org.in/faqFor any change in a given API catalog, the API provider must be ready with the API changes first followed by the API consumer. For example, for any change in FIP API catalog, FIPs need to be ready with the new version first followed by AA. For more details pertaining to the new version adoption, kindly refer to the NBFC-AA API Specification Adoption Strategy Document.
https://api.rebit.org.in/faqAccount Aggregator may provide a facility to the customer to view the Financial Information with his explicit consent using AA Client. In this case, the customer himself is the consumer of data and hence POST /Consent request submitted by AA Client to AA server will contain DataConsumer id as customer VUA and type as 'USER'
https://api.rebit.org.in/faq
POST /Consent/Notification API hosted by FIP and FIU is called by AA in case customer updates the consent status.
FIP or FIU can use the POST /Consent/Notification API hosted by AA to raise a consent status update request to revoke consent. AA can perform the actual consent status update as per the request received after customer confirmation and notify FIP/FIU.
The POST /Consent/Notification API of AA can be called by FIU/AA Client/FIP to request for consent status update for specific use cases. However, based on the notifier type, the allowed consent status enumeration values should be restricted as follows:
-> AA Client - ACTIVE, REJECTED, REVOKED, PAUSED
-> FIU - REVOKED
-> FIP - REVOKED
For the account discovery process, at least one strong identifier must be used. An identifier which can be authenticated is called as a strong identifier. The AAs use a strong identifier to authenticate customer at the time of registration. Typically, the same identifier is passed to the FIP to discover accounts. However, in case AAs are passing some other strong identifier to FIP for account discovery, AAs must authenticate that strong identifier before passing it to the FIP.
https://api.rebit.org.in/faqPOST /Consent/Notification API hosted by FIP and FIU is called by AA in case customer updates the consent status. FIP or FIU can use the POST /Consent/Notification API hosted by AA to raise a consent status update request to revoke consent. AA can perform the actual consent status update as per the request received after customer confirmation and notify FIP/FIU.
https://api.rebit.org.in/faq