DESC:
FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003

COMPLETE SPECIFICATION
(See section 10 and rule 13)
1. TITLE OF THE INVENTION
METHOD AND SYSTEM FOR MANAGING ONBOARDING PROCESS
2. APPLICANT(S)
NAME NATIONALITY ADDRESS
JIO PLATFORMS LIMITED INDIAN OFFICE-101, SAFFRON, NR. CENTRE POINT, PANCHWATI 5 RASTA, AMBAWADI, AHMEDABAD 380006, GUJARAT, INDIA
3.PREAMBLE TO THE DESCRIPTION

THE FOLLOWING SPECIFICATION PARTICULARLY DESCRIBES THE NATURE OF THIS INVENTION AND THE MANNER IN WHICH IT IS TO BE PERFORMED.

FIELD OF THE INVENTION
[0001] The present invention relates to communication systems, more particularly relates to a system and method for managing an onboarding process of Application Programming Interface (API) providers and their APIs with Common API Framework (CAPIF).
BACKGROUND OF THE INVENTION
[0002] The demand for wireless data traffic has seen a significant increase since the deployment of 4G communication systems. As a result, there has been a concerted effort to develop an improved communication system known as 5th Generation (5G) network. This innovative technology aims to address the escalating demand for data connectivity and offer enhanced features and capabilities.
[0003]
[0004] The 3rd Generation Partnership Project (3GPP) plays a crucial role in setting the standards for mobile communication systems. In 3GPP, API driven steps are defined to onboard an authorized API provider to a Common Application Programming Interface Frameworks (CAPIF) system. These API providers use an API management platform to build, expose, and operate APIs using the CAPIF core function. However, onboarding external 3rd party API providers or non-3GPP API providers can be challenging and error-prone due to the lack of defined steps or methods in 3GPP. Without established guidelines, the process becomes difficult to navigate, potentially leading to complications. As a result, the integration of these external providers into the 3GPP ecosystem may face hurdles and require additional efforts to ensure compatibility and seamless functionality.
[0005] Hence there is a need for a system and method for managing an onboarding process of 3rd party and non-3GPP API providers and their APIs with CAPIF.
SUMMARY OF THE INVENTION
[0006] One or more embodiments of the present disclosure provide a method and system for managing an onboarding process.
[0007] In one aspect of the present invention, the system for managing the onboarding process is disclosed. The system includes a receiving unit configured to receive information associated with one of an Application Programming Interface (API) provider and an API. The system further includes a validation unit configured to validate the information associated with the received API provider and the API. The system further includes an onboarding unit configured to onboard the API provider as authorized consumers of Common API Framework (CAPIF).
[0008] In an embodiment, the onboarding process includes registration, deregistration, and updating of the API provider at the CAPIF. In an embodiment, the information is received via a Command Line Interface (CLI) or a User Interface (UI).
[0009] In an embodiment, the validation is performed based on a structure and parameters of the API. In an embodiment, the system includes a storing unit configured to store data pertaining to the onboarding of the API provider at a database upon onboarding.
[0010] In another aspect of the present invention, the method of managing the onboarding process is disclosed. The method includes the step of receiving information associated with one of an Application Programming Interface (API) provider and an API. The method further includes the step of validating the information associated with received API provider and the API. The method further includes the step of onboarding the API provider as authorized consumers of Common API Framework (CAPIF) functionalities.
[0011] In another aspect of the invention, a non-transitory computer-readable medium having stored thereon computer-readable instructions is disclosed. The computer-readable instructions are executed by a processor. The processor is configured to receive information associated with one of an Application Programming Interface (API) provider and an API. The processor is configured to validate the information associated with the received API provider and the API. The processor is configured to onboard the API provider as authorized consumers of Common API Framework (CAPIF).
[0012] Other features and aspects of this invention will be apparent from the following description and the accompanying drawings. The features and advantages described in this summary and in the following detailed description are not all-inclusive, and particularly, many additional features and advantages will be apparent to one of ordinary skill in the relevant art, in view of the drawings, specification, and claims hereof. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter.
BRIEF DESCRIPTION OF THE DRAWINGS
[0013] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Some drawings may indicate the components using block diagrams and may not represent the internal circuitry of each component. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of electrical components, electronic components or circuitry commonly used to implement such components.
[0014] FIG. 1 is an exemplary block diagram of an environment for managing an onboarding process, according to one or more embodiments of the present invention;
[0015] FIG. 2 is an exemplary block diagram of a system for managing the onboarding process, according to one or more embodiments of the present invention;
[0016] FIG. 3 is an exemplary block diagram of an architecture of the system of the FIG. 2, according to one or more embodiments of the present invention;
[0017] FIG. 4 is a signal flow diagram for managing the onboarding process, according to one or more embodiments of the present invention; and
[0018] FIG. 5 is a schematic representation of a method of managing the onboarding process, according to one or more embodiments of the present invention.
[0019] The foregoing shall be more apparent from the following detailed description of the invention.
DETAILED DESCRIPTION OF THE INVENTION
[0020] Some embodiments of the present disclosure, illustrating all its features, will now be discussed in detail. It must also be noted that as used herein and in the appended claims, the singular forms "a", "an" and "the" include plural references unless the context clearly dictates otherwise.
[0021] Various modifications to the embodiment will be readily apparent to those skilled in the art and the generic principles herein may be applied to other embodiments. However, one of ordinary skill in the art will readily recognize that the present disclosure including the definitions listed here below are not intended to be limited to the embodiments illustrated but is to be accorded the widest scope consistent with the principles and features described herein.
[0022] A person of ordinary skill in the art will readily ascertain that the illustrated steps detailed in the figures and here below are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[0023] The system and method of the present invention provides an easy method to onboard all API providers and their APIs, including from non-3GPP and 3rd party API providers. The present invention provides a seamless integration method for API providers to connect with Common Application Programming Interface Framework (CAPIF) and use CAPIF features to expose their APIs to API consumers. The consumers or clients can connect to various backend systems, whether on-premises or in the cloud.
[0024] FIG. 1 illustrates an exemplary block diagram of an environment 100 for managing an onboarding process, according to one or more embodiments of the present disclosure. In this regard, the environment 100 includes a User Equipment (UE) 102, a server 104, a network 106 and a system 108 communicably coupled to each other for managing the onboarding process.
[0025] As per the illustrated embodiment and for the purpose of description and illustration, the UE 102 includes, but not limited to, a first UE 102a, a second UE 102b, and a third UE 102c, and should nowhere be construed as limiting the scope of the present disclosure. In alternate embodiments, the UE 102 may include a plurality of UEs as per the requirement. For ease of reference, each of the first UE 102a, the second UE 102b, and the third UE 102c, will hereinafter be collectively and individually referred to as the “User Equipment (UE) 102”.
[0026] In an embodiment, the UE 102 is one of, but not limited to, any electrical, electronic, electro-mechanical or an equipment and a combination of one or more of the above devices such as virtual reality (VR) devices, augmented reality (AR) devices, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, mainframe computer, or any other computing device.
[0027] The environment 100 includes the server 104 accessible via the network 106. The server 104 may include, by way of example but not limitation, one or more of a standalone server, a server blade, a server rack, a bank of servers, a server farm, hardware supporting a part of a cloud service or system, a home server, hardware running a virtualized server, one or more processors executing code to function as a server, one or more machines performing server-side functionality as described herein, at least a portion of any of the above, some combination thereof. In an embodiment, the entity may include, but is not limited to, a vendor, a network operator, a company, an organization, a university, a lab facility, a business enterprise side, a defense facility side, or any other facility that provides service.
[0028] The network 106 includes, by way of example but not limitation, one or more of a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, or some combination thereof. The network 106 may include, but is not limited to, a Third Generation (3G), a Fourth Generation (4G), a Fifth Generation (5G), a Sixth Generation (6G), a New Radio (NR), a Narrow Band Internet of Things (NB-IoT), an Open Radio Access Network (O-RAN), and the like.
[0029] The network 106 may also include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. The network 106 may also include, by way of example but not limitation, one or more of a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, a VOIP or some combination thereof.
[0030] The environment 100 further includes the system 108 communicably coupled to the server 104 and the UE 102 via the network 106. The system 108 is configured for managing the onboarding process. As per one or more embodiments, the system 108 is adapted to be embedded within the server 104 or embedded as an individual entity.
[0031] Operational and construction features of the system 108 will be explained in detail with respect to the following figures.
[0032] FIG. 2 is an exemplary block diagram of the system 108 for managing the onboarding process, according to one or more embodiments of the present invention.
[0033] As per the illustrated embodiment, the system 108 includes one or more processors 202, a memory 204, a user interface 206, and a database 208. For the purpose of description and explanation, the description will be explained with respect to one processor 202 and should nowhere be construed as limiting the scope of the present disclosure. In alternate embodiments, the system 108 may include more than one processor 202 as per the requirement of the network 106. The one or more processors 202, hereinafter referred to as the processor 202 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, single board computers, and/or any devices that manipulate signals based on operational instructions.
[0034] As per the illustrated embodiment, the processor 202 is configured to fetch and execute computer-readable instructions stored in the memory 204. The memory 204 may be configured to store one or more computer-readable instructions or routines in a non-transitory computer-readable storage medium, which may be fetched and executed to create or share data packets over a network service. The memory 204 may include any non-transitory storage device including, for example, volatile memory such as RAM, or non-volatile memory such as disk memory, EPROMs, FLASH memory, unalterable memory, and the like.
[0035] In an embodiment, the user interface 206 includes a variety of interfaces, for example, interfaces for a graphical user interface, a web user interface, a Command Line Interface (CLI), and the like. The user interface 206 facilitates communication of the system 108. In one embodiment, the user interface 206 provides a communication pathway for one or more components of the system 108. Examples of such components include, but are not limited to, the UE 102 and the database 208.
[0036] The database 208 is one of, but not limited to, a centralized database, a cloud-based database, a commercial database, an open-source database, a distributed database, an end-user database, a graphical database, a No-Structured Query Language (NoSQL) database, an object-oriented database, a personal database, an in-memory database, a document-based database, a time series database, a wide column database, a key value database, a search database, a cache databases, and so forth. The foregoing examples of database 208 types are non-limiting and may not be mutually exclusive e.g., a database can be both commercial and cloud-based, or both relational and open-source, etc.
[0037] In order for the system 108 for managing the onboarding process, the processor 202 includes one or more modules. In one embodiment, the one or more modules includes, but not limited to, a receiving unit 210, a validation unit 212, an onboarding unit 214, a storing unit 216, a notification unit 218 and a logging unit 220 communicably coupled to each other for managing the onboarding process.
[0038] The receiving unit 210, the validation unit 212, the onboarding unit 214, the storing unit 216, the notification unit 218 and the logging unit 220 in an embodiment, may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the processor 202. In the examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the processor 202 may be processor-executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the processor may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the memory 204 may store instructions that, when executed by the processing resource, implement the processor. In such examples, the system 108 may comprise the memory 204 storing the instructions and the processing resource to execute the instructions, or the memory 204 may be separate but accessible to the system 108 and the processing resource. In other examples, the processor 202 may be implemented by electronic circuitry.
[0039] In one embodiment, the receiving unit 210 of the system 108 is configured to receive information associated with one of an Application Programming Interface (API) provider and an API. The API refers to a set of protocols, tools, and definitions that allow different applications and network functions to communicate with each other. The API provider refers to an entity or component that offers a set of APIs to external applications or other network functions. The information associated with one of the API provider includes, but not limited to, entity name, functionality, endpoint Uniform Resource Locator (URL), security requirements, rate limits and quotas, documentation, support and Service Level Agreements (SLA). The information associated with the API includes, but not limited to, API name, version, endpoints, methods, parameters, responses, error handling, data formats. The information is received via a Command Line Interface (CLI) or a User Interface (UI).
[0040] The UI is the means by which a user interacts with a computer system, software application, or electronic device. The UI is one of but not limited to Graphical User Interface (GUI), Command-Line Interface (CLI), Touch User Interface (TUI), Natural User Interface (NUI), Voice User Interface (VUI). The CLI is a type of user interface that allows users to interact with the UE 102 or software by typing commands into a console or terminal.

[0041] Upon receiving the information associated with one of the API provider and the API, the validation unit 212 is configured to validate the information associated with the received API provider and the API. The validation is performed based on a structure and parameters of the API. The structure of the API defines how the API is organized and the data it expects and returns. The structure of the API includes, but not limited to, base Uniform Resource Locator (URL), endpoints, Hyper Text Transfer Protocol (HTTP) methods such as (GET, POST, PUT, DELETE), and headers. The parameters of the API include, but not limited to path parameters, query parameters, header parameters, and body parameters. The information associated with received API provider and the API is validated by checking if the API adheres to the defined schema such as JSON schema, XML schema etc., verifying that the API endpoints conform to the expected structure including the correct HTTP methods (GET, POST, PUT, DELETE) and paths, and ensuring that the parameters passed to the API endpoints are valid.

[0042] In an embodiment, if the information associated with received API provider and the API is valid, then the API providers are allowed to be onboarded. Alternatively, if the information associated with received API provider and the API is not valid, then the API providers are not allowed to be onboarded and the information associated with received API provider and the API is updated at the runtime.
[0043] Upon validating the information associated with the received API provider and the API, the onboarding unit 214 is configured to onboard the API provider as authorized consumers of Common API Framework (CAPIF) 306a (as shown in FIG. 3) functionalities. The onboarding refers to a one-time registration process that enables the API invoker to subsequently access the CAPIF 306a and the service APIs. The API invoker refers to the entity which invokes the CAPIF 306a or service APIs. The service API refers to the interface through which a component of the system exposes its services to API invokers by abstracting the services from the underlying mechanisms. The onboarding process includes registration, deregistration and updating of the API provider at the CAPIF 306a.
[0044] The CAPIF 306a is a framework comprising common API aspects that are required to support service APIs. The CAPIF 306a functionalities are designed to simplify and secure the exposure of network capabilities to third-party applications and service providers. The CAPIF 306a functionalities includes, but not limited to onboarding/offboarding of application functions, service discovery and management, event subscription and notification, security and charging.
[0045] Thereafter, in an embodiment, the storing unit 216 is configured to store data pertaining to the onboarding of the API provider at the database 208 upon onboarding. The data includes but not limited to provider information, authentication and authorization, API specifications, technical requirements, SLAs, and documentation.
[0046] Further, in an embodiment, the notification unit 218 is configured to notify one or more subscribers of the onboarding of the API provider upon onboarding. The one or more subscribers of the onboarding of the API provider refers to the entities or individuals who register to use the APIs provided by the API provider. The one or more subscribers includes, but not limited to an individual developer, an organization, and a third-party application.
[0047] Further, in an embodiment, the logging unit 220 is configured to log details associated with activities of the API provider along with a status code upon onboarding. The activities of the API provider includes, but not limited to, API registration, API update, API deletion, subscription management, API usage monitoring, and security management. The status code provides an indication of the success or failure of each activity performed by the API provider. The status code includes 200 ok, 210 created, 204 no content, 400 bad request, 401 unauthorized, 403 forbidden, and 404 not found.
[0048] Therefore, the system 108 provides a seamless integration method for API providers to connect with the CAPIF 306a and use the CAPIF 306a features to expose their APIs to API consumers 302. Further, the system 108 Simplifies on-premises connectivity and configuration if the backend system changes.
[0049] FIG. 3 is an exemplary block diagram of an architecture 300 of the system 108 for managing onboarding process, according to one or more embodiments of the present invention.
[0050] The architecture 300 includes an API consumer 302, an UI API dashboard 304, a common API gateway 306, a plurality of API providers (an API provider-1 308a, an API provider-2 308b, an API provider-N 308c), an API publisher 310, communicably coupled to each other via the network 106.
[0051] In an embodiment, the common API gateway 306 may be a part of a subscriber system. The common API gateway 306 may be used to expose, secure, and manage backend applications, infrastructure and/or network systems as published APIs. The API consumer 302 comprises an API developer 302a, an API playground 302b, and an enterprise architecture 302c. The API developer 302a communicates with the common API gateway 306 and is used to provide access to and resources for the published APIs to internal and external developers. For example, internal and external developers communicate with the API developer 302a to access the published APIs that the developers use to build applications against, such as web and mobile applications. The API playground 302b is a tool allowing developers to browse and explore all APIs. The API playground 302b exposes all API endpoints and provides a convenient testbed to perform queries. The API enterprise architecture 302c is used to connect enterprise applications and backend resources. In the enterprise architecture 302c, APIs are critical as businesses adopt new technologies and applications.
[0052] Similar to the API consumer 302, the API publisher 310 comprises an API developer 310a, an API playground 310b, and an enterprise architecture 310c. Further, the API publisher 310 comprises a subscription engine 312 which manages the user subscriptions, billing and quota enforcement and a marketplace engine 314 which serves as a platform for listing APIs, allowing consumers to discover, evaluate, and subscribe to APIs. The API Publisher 310 may also include, but not limited to documentation engine which generate and maintain comprehensive API documentation, security engine which ensures that APIs are protected from unauthorized access and other security threats and update and maintenance engine which ensures that APIs are kept up to date with new features and improvement without disrupting existing users.
[0053] The common API gateway 306 is a provisioning server hosting application logic for create/modify/display/delete of subscription information, authentication information, and equipment information. The gateway supports Network Configuration (NETCONF)/Secure Shell (SSH) and Restful/HTTP interfaces. The gateway supports both client and server-side validation of input parameters for syntax and semantic checks. The common API gateway 306 provides lightweight CLI for all provisioning requirements.
[0054] The common API gateway 306 comprises one or more modules, the CAPIF 306a, an Access Management System (AMS) 306b, an Identity and Access Management (IAM) 306d and an Elastic Load Balancer (ELB) 306c. The CAPIF 306a module is a complete 3GPP API framework that covers functionality related to on-boarding and off-boarding of API invokers, register and release APIs that need to be exposed, discovering APIs by third entities, as well as authorization and authentication. The AMS 306b module outsources the task of providing ongoing support for applications to an external provider that specializes in this type of maintenance and monitoring. The IAM 306d module is used for authentication and authorization of a third-party consumers. The ELB 306c module automatically distributes incoming application traffic across multiple targets and virtual appliances in one or more availability zones.
[0055] The common API gateway 306 securely communicates with the API publisher 310. In an embodiment, common API gateway 306 generates a Secure Sockets Layer (SSL) certificate and then uses its public key to verify and communicate with the API publisher 310.
[0056] The common API gateway 306 is further configured to display a UI API dashboard 304. The UI API dashboard 304 stores and maintains the data related to the plurality of API providers (the API provider-1 308a, the API provider-2 308b, the API provider-N 308c) and the API consumers 302, their subscriptions, usage, usage history and balance subscription data for each API provider. The UI API dashboard 304 uses a data analytics engine to show the data of API providers in a way of charts and tables. The UI API dashboard 304 further shows the data related to number of times the API invoked/ click to call subscriptions initiated and used.
[0057] In an embodiment, typically the API consumer 302 may be the third-party application provider having a service agreement with the CAPIF 306a of the common API gateway 306. The API provider hosts one or more service APIs and has a service API arrangement with CAPIF provider to offer the service APIs to the API consumer 302. The CAPIF provider and the API provider may be part of the same organization in which the business relationship between the two is internal to a single organization. The CAPIF provider and the API provider may be part of different organizations, in which the business relationship between the two must exist.
[0058] FIG. 4 is a signal flow diagram for managing onboarding process, according to one or more embodiments of the present invention. For the purpose of description, the signal flow diagram is described with the embodiments as illustrated in FIG. 2 and should nowhere be construed as limiting the scope of the present disclosure.
[0059] At step 402, the receiving unit 210 is configured to receive the information associated with one of the API provider and the API. The information is received via the CLI or the UI.
[0060] At step 404, upon receiving the information associated with the API provider and the API, the validation unit 212 is configured to validate the information associated with the received API provider and the API. The validation is performed based on the structure and parameters of the API.
[0061] At step 406, upon validation the information associated with the received API provider and the API, the onboarding unit 214 is configured to onboard the API provider as authorized consumers of CAPIF 306a functionalities. The onboarding process includes registration, deregistration and updating of the API provider at the CAPIF 306a.
[0062] At step 408, upon onboarding the API provider, the pertaining to the onboarding of the API provider is stored by the storing unit 216 at the database 208.
[0063] At step 410, upon onboarding the API provider, the notification unit 218 is configured to notify the one or more subscribers of the onboarding of the API provider.
[0064] At step 412, upon onboarding the API provider, the logging unit 220 is configured to log the details associated with activities of the onboarding of the API provider.
[0065] FIG. 5 is a flow diagram of a method 500 for managing onboarding process, according to one or more embodiments of the present invention. For the purpose of description, the method 500 is described with the embodiments as illustrated in FIG. 2 and should nowhere be construed as limiting the scope of the present disclosure.
[0066] At step 502, the method 500 includes the step of receiving the information associated with one of the API provider and the API by the receiving unit 210. The information is received via the CLI or the UI.
[0067] At step 504, the method 500 includes the step of validating the information associated with the received API provider and the API by the validation unit 212. The validation is performed based on the structure and parameters of the API.
[0068] At step 506, the method 500 includes the step of onboarding the API provider as authorized consumers of the CAPIF 306a functionalities. The onboarding process includes registration, deregistration, and updating of the API provider at the CAPIF 306a. Further, upon onboarding, the data pertaining to the onboarding of the API provider is stored at the database 208 by the storing unit 216. Further, upon onboarding the one or more subscribers of the onboarding of the API provider is notified by the notification unit 218. Further, upon onboarding the details associated with the activities of the API provider along with the status codes are logged by the logging unit 220.
[0069] The present invention further discloses a non-transitory computer-readable medium having stored thereon computer-readable instructions. The computer-readable instructions are executed by the processor 202. The processor 202 is configured to receive information associated with one of the API provider and the API. The processor 202 is further configured to validate the information associated with the received API provider and the API. The processor 202 is further configured to onboard the API provider as authorized consumers of CAPIF 306a functionalities.
[0070] A person of ordinary skill in the art will readily ascertain that the illustrated embodiments and steps in description and drawings (FIG.1-5) are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the disclosed embodiments.
[0071] The present disclosure incorporates technical advancement that it provides a seamless integration method for API providers to connect with CAPIF and use CAPIF features to expose their APIs to API consumers. The consumers or clients can connect to various backend systems, whether on-premises or in the cloud. The solution enables consumers to discover the desired services or interfaces they require. Additionally, it simplifies the process of connecting to on-premises systems and makes configuration easier in case there are changes to the backend system.
[0072] The present invention offers multiple advantages over the prior art and the above listed are a few examples to emphasize on some of the advantageous features. The listed advantages are to be read in a non-limiting manner.

REFERENCE NUMERALS

[0073] Environment- 100
[0074] User Equipment (UE)- 102
[0075] Server- 104
[0076] Network- 106
[0077] System -108
[0078] Processor- 202
[0079] Memory- 204
[0080] User Interface- 206
[0081] Database- 208
[0082] Receiving Unit- 210
[0083] Validating Unit- 212
[0084] Onboarding unit- 214
[0085] Storing Unit- 216
[0086] Notification Unit- 218
[0087] Logging Unit- 220
[0088] API Consumer- 302
[0089] Developer- 302a
[0090] Playground -302b
[0091] Enterprise- 302c
[0092] UI API dashboard- 304
[0093] Common API Gateway- 306
[0094] CAPIF- 306a
[0095] AMS- 306b
[0096] ELB-306c
[0097] IAM- 306d
[0098] Plurality of API providers (API provider-1, API provider-2, API provider-N) – 308a, 308b, 308c
[0099] API Publisher- 310
[00100] Developer- 310a
[00101] Playground- 310b
[00102] Enterprise- 310c
[00103] Subscription Engine- 312
[00104] Market Place- 314
,CLAIMS:CLAIMS:
We Claim:
1. A method (500) of managing onboarding process, the method (500) comprising the steps of:
receiving, by one or more processors (202), information associated with one of an Application Programming Interface (API) provider and an API;
validating, by the one or more processors (202), the information associated with the received API provider and the API; and
onboarding, by the one or more processors (202), the API provider as authorized consumers of Common API Framework (CAPIF) (306a) functionalities.

2. The method (500) as claimed in claim 1, wherein the onboarding process includes registration, deregistration, and updating of the API provider at the CAPIF (306a).

3. The method (500) as claimed in claim 1, wherein the information is received via a Command Line Interface (CLI) or a User Interface (UI).

4. The method (500) as claimed in claim 1, wherein the validation is performed based on a structure and parameters of the API.

5. The method (500) as claimed in claim 1, wherein upon onboarding, the method (500) comprises the step of storing, by the one or more processors (202), data pertaining to the onboarding of the API provider at a database (208).

6. The method (500) as claimed in claim 1, wherein upon onboarding, the method (500) comprises the step of notifying, by the one or more processors (202), one or more subscribers of the onboarding of the API provider.

7. The method (500) as claimed in claim 1, wherein upon onboarding, the method (500) comprises the step of logging, by the one or more processors (202), details associated with activities of the API provider along with status codes.

8. A system (108) for managing onboarding process, the system (108) comprising:
a receiving unit (210) configured to receive, information associated with one of an Application Programming Interface (API) provider and an API;
a validation unit (212) configured to validate, the information associated with the received API provider and the API; and
an onboarding unit (214) configured to onboard, the API provider as authorized consumers of Common API Framework (CAPIF) (306a) functionalities.

9. The system (108) as claimed in claim 8, wherein the onboarding process includes registration, deregistration, and updation of the API provider at the CAPIF.

10. The system (108) as claimed in claim 8, wherein the information is received via a Command Line Interface (CLI) or a User Interface (UI).

11. The system (108) as claimed in claim 8, wherein the validation is performed based on a structure and parameters of the API.

12. The system (108) as claimed in claim 8, comprising a storing unit (216) configured to store, data pertaining to the onboarding of the API provider at a database (208) upon onboarding.

13. The system (108) as claimed in claim 8, comprising a notification unit (218) configured to notify, one or more subscribers of the onboarding of the API provider upon onboarding.

14. The system (108) as claimed in claim 8, comprising a logging unit (220) configured to log, details associated with activities of the API provider along with status codes upon onboarding.