Assets

Overview

Developer Portal offers you an exclusive platform to safely expose your APIs to your target developers and partners.

Developer Portal also allows developers to self-register, learn about these APIs, and use the APIs in their applications.

To prepare to manage the APIs that you plan to make available in Developer Portal, consider the following questions:

How many Developer Portal instances you might need?
Which organizations might use Developer Portal?
Which users in the organization might use Developer Portal to consume the published APIs?
Which taxonomies and categories are required to organize the APIs?

For each Developer Portal instance, there is a Developer Portal object registered with the API Provider. A Developer Portal is associated with an organization. Multiple Developer Portal instances can share the same organization.

An API can be published to multiple Developer Portal instances. Developer Portal is capable of managing APIs published from API Gateway or any other provider application.

When an API is unpublished (removed) from Developer Portal, its metadata is deleted from Developer Portal, and the API is no longer available for access.

In addition to APIs published from a provider, you can also create APIs in Developer Portal by providing a corresponding specification. The APIs created in Developer Portal need not be associated with any providers.

You can download the published APIs from Developer Portal to have a copy of the API specification.

How do I create an API?

You can create an API using a file, URL, or by providing the source content.

Developer Portal supports the publishing of OData APIs from provider applications such as API Gateway. However, you cannot create OData APIs in Developer Portal by providing a specification.

This use case starts when you want to create an API and ends when you have successfully created an API.

Before you begin:

Ensure that you have the file, URL, or the required content for creating the API.

In this example, you create an API Petstore using the https://petstore.swagger.io/v2/swagger.json URL. The API is assigned to the provider, Provider1 and the community, Mobile_app_developer.

To create an API

Click the menu options icon from the title bar and click Manage assets.
Click APIs.
Click Create API.
Provide Petstore in the Name field.
Select Swagger from the Type list.
Select Provider1 in the Provider field.
Select Mobile_app_developer from the Community field.
Select URL from the Import with section and provide https://petstore.swagger.io/v2/swagger.json in the field.
Click Create.

The API is created. You can view the API from the API gallery page and the Manage APIs page.

Alternative steps

In Step 4, select any of the following API types from the Type list:
- Open API. To create a REST API using an Open API specification.
- RAML. To create a REST API using a RAML specification.
- WSDL. To create a SOAP API using a WSDL specification.
In Step 7, select the required provider.

If you are creating the API for a third-party API gateway, ensure that the gateway is registered for the value to be available in the Provider field.
In Step 7, provide the following inputs to create an API from the Import with section:
- File. To create API from a file. Click Browse and select the required file.
- Content. To create API from the given content. Provide the required parser content using which the API has to be created. Ensure that the content does not have references to external files.

Next steps:

If the API lifecyle feature is enabled, then the newly created API is kept in the Draft state. For information about the API lifecycle, see Lifecycle Management of APIs and Packages.
Move the API to the Live state to make it available for consumers. For information on moving APIs to the Live state, see How do I change the state of an API to expose it to consumers?

How do I edit the basic attributes of an API?

Basic attributes of APIs include the API name, description, type, providers and communities associated with an API, and the API source.

This use case starts when you want to edit the basic attributes of an API and ends when you save your changes.

In this example, consider renaming the Pet_v1 API as Petstore_v1.

To edit the basic details of an API

Click the menu options icon from the title bar and click Manage assets.
Click APIs.

The list of APIs appears.
Click the edit icon next to the Pet_v1 API.
Click Save.

Your changes are saved. The API is removed from the public community. So, only the users who are a part of the Mobile_app_developer community can view or try the API.

How do I edit the advanced attributes of an API?

Advanced attributes of APIs include the API logo or icon, supporting documents, categories, and summary and description of the API resources.

Developer Portal supports providing of Markdown text and text in the supported languages for the following API attributes:

API summary and description
API categories such as tags, business terms, API grouping, and maturity status
API documents
Resource summary and description
Method summary and description

Note

For security reasons, it is recommended that you add authentic and valid Markdown content.

Sample Markdown text:

This use case starts when you want to edit the advanced attributes of an API and ends when you saved your changes.

In this example, consider adding API tags under API categories of the API, Petstore.

To edit the advanced details of an API

Click the menu options icon from the title bar and click Manage assets.
Click APIs.

The list of APIs appears.
Click the enrich icon next to the API that you want to edit.
Select API categories from the left pane and provide the new tag, Swagger and press Enter.
Click Save.

The tag is added to the API. Users can filter APIs based on tags in the API gallery page.

Alternative steps

You can provide or modify the following details of the API:
- API info
- API summary and description
- Resource summary and description
- Method summary and description
Sample Markdown text:

In this example, information is given under two different levels of headings.

Then, the output looks like this.

For information on Markdown text, see https://www.markdownguide.org/extended-syntax/.

How do I create a new version of an API?

When you create a new version of an API, the API gallery page displays the latest version of the API. You can view all versions of the from the Manage APIs page. The API details page has a drop-down list that displays all API versions.

You can create new versions of an API for the use of a different set of consumers or with different security policies. New data can also be updated to the existing meta-data when you create new versions of your APIs.

The new API has the same metadata but with an updated version. The version can either be a number or a string.

Different versions of an API can be added to different communities and can be associated with different packages.

This use case starts when you want to create a new version of an existing API and ends when you created a new version of an API.

In this example, consider creating a new version of the API, Petstore 2.0 and map the newer version to the Public community.

To create a new version of an API

Click from the title bar and click Manage assets.
Click APIs.

The list of APIs appear.
Click the version icon next to the API, Petstore.
Provide 2.0 in the Version field.
Select Swagger from the Type list.
Select Provider1 in the Provider field.
Select Public from the Community field.
Select URL from the Import with section and provide https://petstore.swagger.io/v2/swagger.json in the field.
Click Save.

A new version of the API, Petstore is created.

Note

When you version an API, you can create versions from the newer version of the API and not from the older version.

Alternative steps

You can update the API by uploading a new file or by providing a new URL or pasting new content.
You can also map the API to another provider.

Next steps

All consumers can view the newer verison of the API as it is a part of the public community.
If the API lifecyle feature is enabled, then the newly created version is kept in the Draft state. For information about the API lifecycle, see Lifecycle Management of APIs and Packages.
Move the API to the Live state to make it available for consumers. For information on moving APIs to the Live state, see How do I change the state of an API to expose it to consumers?

Viewing Code Snippets of REST APIs

You can view the sample code snippets for the required REST API resources.

When you want to invoke any endpoint from a REST API, you can view the sample code to invoke the endpoint in a language of your choice.

To view client code snippets

From the API gallery page, click the view icon next to the required API.

The API details screen appears.
Select the required API resource.
Turn the Show code slider on to view the sample code for the selected resource.

You can also select the required language for the code snippet.
Optional. Click Copy to copy the sample code.
Turn the Show code slider off to hide the sample code.

Downloading Client Software Development Kit (SDK) for REST API resources

As an API consumer, after you have selected the required REST API, you would require the software development kit (SDK) of the API to consume the API resources to build your custom applications(web or mobile). You can download client SDK for the required REST API.

To download client SDK

From the API gallery page, click the view icon next to the required API.

The API details screen appears.
Click the download SDK icon to download the client SDK for the API.
Select the language that you require for your development kit.
Click Download.

The SDK is downloaded as zip file. The downloaded file includes the dependencies of the HTTP client for the selected language.

Next steps:

Unzip the downloaded SDK from the default download location of your browser to view the SDK file contents.

Trying APIs

Developer Portal allows you to try an API with required parameters.

You can try the required resource of an API by providing corresponding parameter values. You must also provide sufficient authorization details to have access to the API.

As an API consumer, it is important to test the endpoints of an API before putting them to use. Hence, Software AG recommends that you always test an API before consuming.

Trying a REST API

This section explains how you can test a REST API.

Pre-requisites

If the API that you are trying is protected with API key, JWT, or OAuth, then create an application to establish your identification. For information about creating applications, see Creating an application.

To try a REST API

Navigate to the Try API page using one of the following ways:
- Click the Tryout icon in the corresponding API tile. Or,
- Click Try API from the API details page of the corresponding API.
The Try API page appears. The resources that you can test appear in the left pane.
Select a resource and the required method.
Provide the following values in the Parameters tab:
- Key. Key value of the parameter.
- Value. Value of the corresponding key parameter.
You can click Add new and add multiple entries.
Provide the following required values in the Headers tab:
- Key. Value of the header key.
- Value. Value of the corresponding key parameter.
You can click Add new and add multiple entries.
Provide the authorization details from the Authorization tab.

For information about the authorization types and required inputs, see Authorization fields.
Select the required request form from the Request body tab and provide your request:
- form-data. To send your request in the form of the key-value pairs. You can select Text and provide your form key and value or select File and attach the request file.
- x-www-form-encoded. To send your request in the form of the encoded key-value pairs.
- raw. To provide any request. You can provide the request in JSON or XML format.
- None. To send the test request without a request body.
Click Send.

The response body and headers appear in their respective sections.

Trying a SOAP API

This section explains how you can test a SOAP API.

Pre-requisites

To try a SOAP API

Navigate to the Try API page using one of the following ways:
- Click the Tryout icon in the corresponding API tile. Or,
- Click Try API from the API details page of the corresponding API.
The Try API page appears. The SOAP methods that you can test appear in the left pane.
Select the required method.
Provide the following values in the Parameters tab:
- Key. Key value of the parameter.
- Value. Value of the corresponding key parameter.
You can click Add new and add multiple entries.
Provide the required header details from the Headers tab:

To include header key value combinations, provide the following:
- Key. Value of the header key.
- Value. Value of the corresponding key parameter.
  
  You can click Add new and add multiple entries.
To include a SOAP header:
- Name. A unique name to distinguish the provided SOAP headers, if there are multiple headers.
- Click Add new namespace URI to provide unique Key elements and corresponding Value attributes for the header content. You can provide multiple key and value combinations by clicking Add new namespace URI.
Header content.

You can click Add SOAP header to provide more headers.
Provide the authorization details from the Authorization tab.

For information about the authorization types and required inputs, see Authorization fields.
If the SOAP API is protected with web service security (WSS) select the required authorization method from the Web Service Security tab:
- WSS user token. Select this to provide WSS user name and password.
- Provide the user name and password required for WSS authorization.
- Select the Add nonce check box to include nonce, which is a randomly generated number that is included in the request header sent to the API server. Nonce is generated every time a request is sent to the API server and thus, adding a nonce to the request along with WSS user token prevents reuse of old communications.
- Select the Add creation time check box to add a timestamp that the nonce was created. This value helps server to ensure that the outdated nonce values are not reused.
- Select Password text to send password as plain text. Else, select Password digest to encrypt the password.
- WSS SAML assertion. Select this to include SAML assertion for WSS authorization. You can either paste the assertion or upload the assertion file.
You can include both, WSS user token and SAML assertion, in your request. You can select either of these options, provide the required details, and then the other option without pressing Clear. So, the details provided for both options are included to the request.
In the Request body tab, provide your request in the form of key-value pairs or raw text.
Click Send.

The response body and headers appear in their respective sections.

Trying a OData API

This section explains how you can test a OData API.

Pre-requisites

To try a OData API

Navigate to the Try API page using one of the following ways:
- Click the Tryout icon in the corresponding API tile. Or,
- Click Try API from the API details page of the corresponding API.
The Try API page appears. The resources that you can test appear in the left pane.
Expand the required resource and click the required method.
In the Query builder tab, select the required query parameters and click Add.

The specified parameters are included as a query in the request URL.
Provide the following values in the Parameters tab:
- Key. Key value of the parameter.
- Value. Value of the corresponding key parameter.
You can click Add new and add multiple entries.
Provide the following required values in the Headers tab:
- Key. Type a header key value.
- Value. Type the corresponding value of the key parameter.
You can click Add new and add multiple entries.
Provide the authorization details from the Authorization tab.

For information about the authorization types and required inputs, see Authorization fields.
Select the required request form from the Request body tab and provide your request:
- form-data. To send your request in the form of the key-value pairs. You can select Text and provide your form key and value or select File and attach the request file.
- x-www-form-encoded. To send your request in the form of the encoded key-value pairs.
- raw. To provide any request. You can provide the request in JSON or XML format.
- None. To send the test request without a request body.
Click Send.

The response body and headers appear in their respective sections.

Authorization fields

This section lists the steps to provide authorization details, for testing APIs, based on the authorization type applied to the corresponding APIs:

Authorization type	Procedure
For APIs protected with API key	Select the required application from the Applications field. Select API Key from the Authorization type field. The test request is sent to the API server with the API key of the selected application.
For APIs that require basic authentication	Select Basic auth from the Authorization type field. Provide the user credentials and click Update. The test request is sent with the selected authorization details.
For APIs protected with JWT	Select the required application from the Applications field. Select JWT from the Authorization type field. The JWT tokens available for the selected application appear in the Available tokens section. You can select a token from the list or request for a new one. Click to get a new access token. The Create new token page appears. Provide the credentials associated with the JWT authorization and click Get token. The token appears in the Available token section. Validity of token’s are based on the duration specified in API Gateway. Select the created token. The test request is sent to the API server with the selected token details.
For APIs protected with OAuth	Select the required application from the Applications field. Select OAuth 2.0 from the Authorization type field. The tokens available for the selected application appear in the Available tokens section. You can select a token from the list or request for a new one. Click to get a new access token. The Create new token page appears. Provide a Token name. Select the required Grant type and the required scope. Click Get token. If you had selected the Authorization code or Implicit grant type, the webMethods API Gateway Resource access approval page appears. Select the required scopes and click Approve. Provide your API Gateway credentials and click Sign in. You will be redirected to Developer Portal Try API page. The token appears in the Available token section. Validity of token’s are based on the duration specified in API Gateway. Select the created token. If you had selected Client credentials grant type, then the request token appears without any further action. Select the created token. The test request is sent to the API server with the selected token details.
For APIs that do not require any authentication	Select None from the Authorization type field. The test request is sent to the API server without any authorization.

Custom Asset Management

In addition to APIs and packages, Developer Portal allows you to publish assets of your choice. This empowers providers to publish end-to-end development reference to their consumers.

As a provider, you can publish any kind of reference for your consumers using this feature.

You can add required asset types and define their properties. You can also create a gallery for the custom assets and display on the UI. Like APIs and packages, your end-users can view the custom assets and collaborate over them.

Custom asset publishing involves the following steps:

Add asset type. You have to first add the asset type, and configure its properties. You would have information that you require to describe the assets you publish to Developer Portal. You can specify the corresponding properties to provide information about each asset that you add to your custom gallery.
Add asset details. After defining the asset type, you can add assets along with their corresponding details.
Add asset gallery to Developer Portal. After you add the asset type, you can add the asset gallery to the UI for your consumers to view the custom assets.

The following use cases demonstrate the process of publishing custom assets using an example. These use cases consider Microservices as custom assets and list the steps of publishing them to Developer Portal.

How do I configure the asset types to publish custom assets to Developer Portal?

Before publishing custom assets to Developer Portal, you must configure the asset type. You can add an asset type and configure its properties from the Manage asset type page.

This use case starts when you want to add a custom asset type and ends when you add the required asset type and configure its properties.

In this example, consider adding the asset type, Microservice with the following properties:

Overview. A rich text field that states the overview of the asset (Microservice). This is an optional field.
Microservice document. An option to upload a file (Microservice document). This is an optional field.
Published On. A date time field to provide the date of the asset publish. This is an optional field.
Author. A text field that provides the asset’s author name. This is a mandatory field.

To add the asset type with the specified details

Click the menu option icon from the title bar and click Administration.
Click Manage asset types.
Click Add type.
Provide Microservice in the Name field.
Provide a description in the Description field.
Add the fields based on the information about custom assets that you want to publish.

When you add an asset of the defined type, you must specify values for the configured properties.

To add the Overview field:

a. Click Add properties.

b. Provide Overview in the Name field.

c. Provide Microservice Overview in the Display name field.

d. Select Rich text from the Select property type field.

e. Click Add.

To add the Microservice document field:

a. Click Add properties.

b. Provide Document in the Name field.

c. Provide Microservice Document in the Display name field.

d. Select File from the Select property type field.

e. Click Add.

To add the Published on field:

a. Click Add properties.

b. Provide Published On in the Name and Display name fields.

c. Select Date from the Select property type field.

d. Click Add.

To add the Author field:

a. Click Add properties.

b. Provide Author in the Name field.

c. Provide Author in the Display name field.

d. Select String from the Select property type field.

e. Turn the Required slider on.

f. Click Add.
Click Save.

The asset type is added.

Alternative steps

In Step 6, you can select one of the following from the Select property type to add the corresponding property for the asset type being created:

Property type	Description	Inputs to be provided
Boolean	Includes a boolean value field with options, Yes or No.	Select the default value that must be displayed for the field. Select whether this property is mandatory when adding an asset.
Date time	Includes a date time field.	Select the default date and time that must be displayed in the field. Select whether this property is mandatory when adding an asset.
Enum	Includes a drop-down list.	Provide the values that must be displayed in the Possible values field. You must provide a value and type a comma to provide the next value. Select the default value that must be displayed in the field. Select whether this property is mandatory when adding the asset.
File	Includes a file upload button that you can click to upload a file when you add the asset.	Select whether this property is mandatory when adding the asset. Note You cannot provide a default value for this field.
Image	Includes an image upload button that you can click to upload an image when you add the asset.	Select whether this property is mandatory when adding the asset. Note You cannot provide a default value for this field.
Number	Includes a number field.	Provide the default value that must be displayed in the field. Select whether this property is mandatory when adding an asset.
Rich text	Includes a rich text field.	Provide the default value, with required formatting, to be displayed in the field. Select whether this property is mandatory when adding the asset.
String	Includes a text box.	Provide the default value that must be displayed in the field. Select whether this property is mandatory when adding the asset.
Tags	Includes the tags field for the asset.	Provide the default value that must be displayed in the field. Select whether this property is mandatory when adding the asset.

Note

When you create an asset type, the following properties are added by default:

Icon
Name
Version
Summary
Tags

Ensure that you do not add duplicate of these default properties.

After you add the required list of properties, you can:
- Edit the details of the field by clicking .
- Move the field up or down by clicking or . These fields appear in the order they are created. You can modify the properties as per requirement.
- Remove a field by clicking .

Next steps

Add assets for the added type from the Manage asset page. For the procedure to add assets, see How do I add a custom asset to publish to Developer Portal?
Customize the custom asset gallery and asset details pages. For more information, see How do I add custom asset gallery to UI?
Configure accessibility of the custom asset gallery page. For information on configuring accessibility, see How do I assign access to a custom page?

How do I add a custom asset to publish to Developer Portal?

After you have added the required asset type, you can add the custom assets of the configured type.

This use case starts when you want to add a custom asset and ends when you add the required assets.

In this example, consider adding an asset for the type, Microservice, that is already configured.

To add a custom asset

Click the menu option icon from the title bar and click Administration.
Click Manage assets.
Click Microservice.
Click Add Microservice.
Provide information for the following default fields:

a. Click Browse and select the logo file.

b. Provide User registration in the Name field.

c. Provide 1.0 in the Version field.

d. Provide a summary for the asset.

e. Provide sign in in the Tags field and press Enter.
Provide information for the properties configured for the custom asset type:

a. Provide an overview for the microservice in the Overview field.

b. Click Browse from the Document field and select the required microservices document.

c. Select a date and time from the Published On field.

d. Provide an author name in the Author field.
Click Save.

Next steps

Add the asset gallery and asset details pages to the UI. For more information, see How do I add custom asset gallery to UI?

How do I add custom asset gallery to UI?

You must add the custom asset gallery to UI for the assets to appear in UI. If you have not added this to UI, then it is not exposed to your consumers. For more details, see How do I add a new item to the top navigation bar?

The use case starts when you have added custom assets that has to be displayed in a gallery and ends when you have completed adding the page.

In this example, consider creating a gallery for the Microservice assets.

To add the custom asset gallery to the UI

Click the menu option icon from the title bar and click Administration.
Click the customize icon next to the active theme.
Select Pages and click Add.
From the Add page screen that appears, select Asset gallery page.
Click Next.
Select Microservice from the Select the asset field.
Click Create.

The asset gallery is added to the list of pages.
Click Add to add the asset detail page.
From the Add page screen that appears, select Asset details page.
Click Next.
Select Microservice from the Select the asset field.
Click Create.

The asset details is added to the list of pages.

Next steps

Add custom assets gallery to the top navigation bar. For information about adding a page to the top navigation bar, see How do I add a new item to the top navigation bar?

To add the custom asset gallery to the top navigation, provide the page target URL in the following format:
```
    

 /pages/assets/custom_asset_type/gallery
    
```
For example,

The added custom assets appear in the gallery.

Note

Ensure that you make the changes to the active theme or you apply the theme in which you have made the changes. Also, note you cannot modify the default theme for including custom asset gallery. You must create a new theme and customize it accordingly.

Click the asset to view its details.
Customize the appearance of the asset gallery and asset details pages as per your requirements. For information about customizing pages, see How do I customize a block on a page?
Customize the accessibility of the asset gallery and asset details pages. For information about customizing access of custom pages, see How do I assign access to a custom page?

Applications

When you invoke a protected API from Developer Portal, you need to create an application requesting access to the API from the provider. Through the application, you can request access tokens from the provider by revealing a corresponding authentication such as username and password, OAuth, or JWT details.

During runtime, the provider recognizes the consumer’s identity through the application. The details passed from Developer Portal to the provider enables them to:

Control access to an API at run time (that is, allow only authorized applications to invoke an API).
Monitor an API for violations of a Service-Level Agreement (SLA) for a specified application.
Indicate the application to which a logged transaction event belongs.

You can create, view, and share applications from the Manage applications section.

Developer Portal sends the application requests from consumers to providers using the callback URL of providers. Configuring an incorrect callback URL can lead to communication issues between the provider and Developer Portal.

If an application onboarding strategy is configured, then the applications that you create will be processed based on the configured strategy. For information on configuring an application onboarding strategy, see How do I configure onboarding strategy to process application or subscription requests?

If you do not configure an onboarding strategy, then the registration requests are automatically approved.

You can view the status of requested applications from the Manage applications section. Once an application is approved, you can share the application with other users or user groups to alllow them use the application and invoke the corresponding APIs. When an application is shared, only the application owner can view the analytics and other cannot.

From the Trace application section of an application, you can view the stages that the application has passed through and their corresponding timestamp. These stages include application creation request,

You can trace the status and stages of an application using the Trace application section of an application. This section displays the various stages including application creation request, application request submit, application publish, application scope increase or decrease, and so on with the corresponding time stamp.

How do I configure onboarding strategy to process application or subscription requests?

This use case starts when you want to configure onboarding process to approve or reject the application or subscription registration requests.

Before you begin:

Ensure that you have:

Configured an approval workflow. For information on configuring an approval workflow, see How do I configure an approval workflow to process an internal approval onboarding strategy?
API Administrator privilege.

To configure onboarding strategy to process application or subscription requests

Click the menu options icon from the title bar and click Administration.
Select Onboarding.
From the Application/subscription onboarding section, enable any or all of the required strategies:
- Internal approval. Select the required approval workflow from the Select a flow window that appears when you enable this strategy.
- External approval. Select this if you want to process the requests using an external approval system. You can notify the required external approving system by creating a webhook. For information on configuring user sign up notifications to your external approving system, see How do I configure webhooks to notify user sign up and application requests to an external approval system?
Use the arrow keys next to these strategies to change their order. The strategies are followed by the order they appear.
Click Save.

The onboarding strategy to process application or subscription requests configuration is saved.

Next steps:

Application and package subscription requests are processed based on the onboarding strategy.

Creating an application

You must create applications to invoke protected APIs.

You can create applications for an API from one of the following:

Manage applications screen
API details screen
Try API screen

You can create more than one application for an API.

How do I create an application from Manage applications screen?

This use case starts when you want to create an application and ends when you have created one.

In this example, consider creating an application app1 to access the API, Petstore that is published by the provider, Provider1.

Before you begin:

Ensure you have the API Administrator or the API Provider privilege.

To create an application from the Manage applications screen

Click the menu options icon from the title bar and click Manage applications.

The list of applications appear.
Click Create application.
Select Provider1 from the Stage list.
Select Petstore from the Select API field.
Provide app1 in the Name field.
Select the required callback URL of the provider.
Click Save.

The application is created.

Next steps:

Application is approved based on the configured application onboarding strategy. If there is no onboarding strategy configured to onboard applications, then the application is approved automatically.
Use application to invoke the API.
Perform the following to share an application:
- Click the share icon next to the application you want to share.
- From the Assign user/team screen, select the users or teams with whom you want to share the application. By default, this field displays only the users who belong to your communities.
- Click Assign.
The application is shared with the selected users and teams.
Perform the following to revoke access to an application from specific users or teams:
- Click the share icon next to the application you want to share.
- From the Assign user/ team screen, click the delete icon next to the user or team from whom you want to revoke access.

Note

Only the users who created an application can share or delete the application. When an application is deleted, the users with whom the application was shared can no longer access the application.

Click Assign.

The access to the application is revoked from the selected users and teams.
When you create an application, the request is sent to the corresponding provider and approved based on the settings configured by provider. Applications in Developer Portal are approved based on the configured application onboarding strategy. If there is no onboarding strategy configured to onboard applications, then the application is approved automatically. After an application is approved, the application is ready to use. Check the Status field to ensure that an application is active.

To view the details of an application, click the application name.

You can trace the application’s stage from the Trace your application requests section of the page.

How do I create an application from API details screen?

This use case starts when you want to create an application and ends when you have created one.

To create an application from the API details screen:

From the API gallery page, click the view icon next to the API for which you want to create an application.
In the API details page, click the request application icon .

Note

The request application icon

appears only for the protected APIs.

In the Request application screen, click Request.

If there is an existing application for the selected API, then the following screen appears:

You can select an existing one or create a new one. The application stage and API name appear in the corresponding fields on the Create application page. If you select to use an existing application, the scope of the application increases and you can invoke the API using an existing application.
Provide the application name and description.
Click Save.

The application is created.

Next steps:

Application is approved based on the configured application onboarding strategy. If there is no onboarding strategy configured to onboard applications, then the application is approved automatically.
Use application to invoke the API.

How do I create an application from Try API screen?

This use case starts when you want to create an application and ends when you have created one.

To create an application from the Try API screen

From the API gallery page, click the Try API icon next to the API for which you want to create an application.
In the Try API page, click Create new application.

The application stage and API name appear in the corresponding fields on the Create application page.
Provide the application name and description.
Click Save.

The application is created.

Next steps:

Application is approved based on the configured application onboarding strategy. If there is no onboarding strategy configured to onboard applications, then the application is approved automatically.
Use application to invoke the API.

Approving Application or Package Subscription Requests

If you have configured an approval workflow for approving application and package subscription requests, then approvers can view the pending requests from the Pending approval screen, and approve or reject them. For information about configuring application or package subscription approval workflow, see How do I configure onboarding strategy to process application or subscription requests?.

To approve a pending application or package subscription request

Click the menu options icon from the title bar and click Pending approvals. The list of application requests appears in the Application requests tab.
Optional. Click a request to view more details about the request.
Click next to the required request to approve the request. A confirmation screen appears.
Provide your comments if any in the Reason field, and click Approve.

Alternative steps

In Step 3, you can click to reject the request. Provide your comments, if any and click Reject. When you reject a application onboarding request, package subscription, or an application scope increase request, a notification e-mail is sent to the requestor as per the Approval result e-mail notification template. If you have specified more than one approver, and if one of the approver rejects a request then the notification e-mail is sent to the requestor and the other approvers. For more information on the e-mail notification template, see How do I configure email notification templates?.
To approve or reject multiple requests listed on the Pending approvals screen, select the checkboxes next to the required requests and click Approve or Reject. The selected pending requests are approved or rejected at once.
To approve or reject all requests, select the checkbox in the grid header and click Approve or Reject. All pending requests are approved or rejected at once.

Lifecycle Management of APIs and Packages

By default, all APIs and API packages are accessible by consumers as and when they are published to Developer Portal. But, as an API provider, you have a lot of APIs or API packages that are under construction or maintenance. You can only expose the assets that are mature, tested, or well-documented for consumers. In such cases, the API lifecycle feature in Developer Portal allows you to expose the APIs that are ready for consumption. You can enable or disable this feature as per your requirement.

An API undergoes a lot of stages before it is ready to be exposed. The following section quickly takes you through these stages and the states that you can assign to those APIs:

In general, API developers develop the skeleton of an API, start implementing, mock it for testing responses, and then activate the API and publish it to Developer Portal. After this, API providers can use the Enrich API feature in Developer Portal to include the required logo or localized descriptions to API and its resources, and then test it again to ensure the performance of the API.

You can move API states in the following linear way based on the development of your APIs:

The default lifecycle states available in Developer Portal are:

Draft. Default state of all APIs. The APIs published to the Developer Portal are kept in the Draft state initially. APIs in this state do not appear in API gallery. These are not available for consumers through applications and packages.
Live. APIs that are moved to the Live state appear in API gallery. If you want to prevent consumers from using an API, you can move the particular API in the Live state to the Draft state. Hence, you can move APIs to the Draft state for the maintenance of those APIs.
Retired. You can move the APIs that are no more used to the Retired state. APIs that are moved to this state cannot be moved back to the other states. Only administrators and providers can view the retired APIs and their details. However, you can create new versions from a retired API and expose them to consumers.

Lifecycle Feature Considerations

As an administrator or a provider, you must consider the following when you enable the lifecycle feature for APIs and packages in Developer Portal.

Visibility of assets

The following table lists the visibility and accessibility of assets on the UI based on user persona.

Use case	State of asset	API consumer	API provider	Administrator
View API in API gallery	Draft
	Live
	Retired
View package in API packages (Package gallery)	Draft
	Live
	Retired
Request application (for an API) or subscription (for a package)	Draft
	Live
	Retired
Search an API or package using global search	Draft
	Live
	Retired
Accessing an API or package using deep link URL	Draft
	Live
	Retired

Note

API consumers can access the APIs or packages that are in Draft or Retired state, if they have a valid application or valid subscription associated with the asset.

State of restored APIs When you restore APIs from an archive, the restored APIs retain the same state from the backup archive. If APIs are backed up from an instance in which the API lifecycle feature is not enabled, then the restored APIs are kept in the Draft state.

State of migrated APIs When you migrate APIs to 10.15 from an earlier version of Developer Portal, the migrated APIs are kept in the Draft state. You can change their state as per your requirement.

Creating applications for APIs in Draft state Only administrators or providers can create applications for the APIs that are in the Draft state, in order to test them before exposing to consumers. Consumers cannot view or use those APIs.

How do I enable the lifecycle feature for APIs and packages?

By default, the lifecycle management feature is not enabled. You must enable the feature from the Administration section of Developer Portal to use the feature.

To enable the lifecycle feature

Click the menu options icon from the title bar and click Administration.
Click General.
Turn the Enable lifecycle slider on.
Click Save.

The lifecycle feature for APIs and packages is enabled.

The APIs and packages in the Draft state are not available for the use of consumers.

When you enable the lifecycle feature, all APIs and packages in your Developer Portal instance are moved to the Draft state.

Next steps:

Move the required APIs and packages to the Live state. For information about moving APIs and packages to the Live state, How do I change the state of an API to expose it to consumers? and How do I change the state of a package to expose it to consumers? respectively.

How do I change the state of an API to expose it to consumers?

This use case explains the steps to move an API to the Live state in order to expose it to consumers.

This use case starts when you want to move an API that is in Draft state to the Live state.

In this example, consider the API, API1 that is in the Draft state is moved to the Live state.

To move an API to the Live state

Click the menu options icon from the title bar and click Manage APIs.
Click the change state icon icon next to the API1.
Select Live.
Click Save.

The state of API is changed to Live.

APIs that are moved the Live state appear in the API gallery page.

Next steps:

Consumers can try the APIs that are in the Live state.
Providers can include the Live APIs to API packages and publish them for the use of consumers.

How do I change the state of a Live API for maintenance?

This use case explains the steps to move an API to the Draft state for performing any maintenance activity on that API.

This use case starts when you want to move an API to the Draft state from the Live state .

In this example, consider the same API, API1 that is in Live state moved to the Draft state.

To move an API to the Draft state

Click the menu options icon from the title bar and click Manage APIs.
Click the change state icon icon next to API1.
Select Draft.
Click Save.

The state of API is changed to Draft.

APIs that are moved to the Draft state do not appear in the API gallery page.

Next steps:

Providers or administrators can create applications to test the APIs that are in the Draft state.
Providers can perform the required maintenance activities to the Draft APIs and then change their state to Live for the use of consumers.

How do I change an API’s state to retire it from usage?

This use case starts when you want to retire an API that is in the Live or Draft state to prevent consumers from viewing it.

In this example, consider the API, API1 that is in Live state.

To move an APIs to the Retired state

Click the menu options icon from the title bar and click Manage APIs.
Click the change state icon icon next to the API1.
Select Retired.
Click Save.

The state of API is changed to Retired.

Next steps:

You cannot move the retired APIs to the other states.
You can create new versions of the retired API and expose to your consumers.

How do I change the state of a package to expose it to consumers?

This use case explains the steps to move a package to the Live state to expose it to consumers.

This use case starts when you want to move an package that is in Draft state to the Live state.

In this example, consider the package, Weather that in the Draft state moved to the Live state.

To move a package to the Live state

Click the menu options icon from the title bar and click Manage packages.
Click the change state icon icon next to the package.
Select Live.
Click Save.

The state of package is changed to Live.

Packages that are moved to the Live state appear in the API packages page.

Next step:

Consumers can view the packages that are in the Live state.

How do I change the state of a Live package for maintenance?

This use case explains the steps to move a package to the Draft state for performing any maintenance activity on that API.

This use case starts when you want to move a package to the Draft state from the Live state.

In this example, consider the same package, Weather that is in Live state moved to the Draft state.

To move an package to the Draft state

Click the menu options icon from the title bar and click Manage packages.
Click the change state icon icon next to the package.
Select Draft.
Click Save.

The state of package is changed to Draft.

Packages that are moved to the Draft state do not appear in the API packages page.

Next steps:

Providers can perform the required maintenance activities to the Draft packages and then change their state to Live for the use of consumers.

How do I change a package’s state to retire it from usage?

This use case starts when you want to retire a package that is in the Live or Draft state to prevent it from the view of consumers.

In this example, consider the package, Weather that is in Live state.

To move a package to the Retired state

Click the menu options icon from the title bar and click Manage packages.
Click the change state icon icon next to the package.
Select Retired.
Click Save.

The state of package is changed to Retired.

You cannot move the retired packages to the other states.