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:

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

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

  2. Click APIs.

  3. Click Create API.

  4. Provide Petstore in the Name field.

  5. Select Swagger from the Type list.

  6. Select Provider1 in the Provider field.

  7. Select Mobile_app_developer from the Community field.

  8. Select URL from the Import with section and provide https://petstore.swagger.io/v2/swagger.json in the field.

  9. Click Create.

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

Alternative steps

  1. 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.

  2. 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.

  3. 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:

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

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

  2. Click APIs.

    The list of APIs appears.

  3. Click the edit icon next to the Pet_v1 API.

  4. 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:

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

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

  2. Click APIs.

    The list of APIs appears.

  3. Click the enrich icon next to the API that you want to edit.

  4. Select API categories from the left pane and provide the new tag, Swagger and press Enter.

  5. Click Save.

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

Alternative steps

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

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

  2. Click APIs.

    The list of APIs appear.

  3. Click the version icon next to the API, Petstore.

  4. Provide 2.0 in the Version field.

  5. Select Swagger from the Type list.

  6. Select Provider1 in the Provider field.

  7. Select Public from the Community field.

  8. Select URL from the Import with section and provide https://petstore.swagger.io/v2/swagger.json in the field.

  9. 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.

In the example, note that the older API does not have the version icon appearing next to it.

Alternative steps

  1. You can update the API by uploading a new file or by providing a new URL or pasting new content.

  2. You can also map the API to another provider.

Next steps

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

  1. 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.

  2. Select a resource and the required method.

  3. 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.

  4. 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.

  5. Provide the authorization details from the Authorization tab.

    For information about the authorization types and required inputs, see Authorization fields.

  6. 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.

  7. 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

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 SOAP API

  1. 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.

  2. Select the required method.

  3. 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.

  4. 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.

  5. Provide the authorization details from the Authorization tab.

    For information about the authorization types and required inputs, see Authorization fields.

  6. 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.

  7. In the Request body tab, provide your request in the form of key-value pairs or raw text.

  8. 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

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 OData API

  1. 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.

  2. Expand the required resource and click the required method.

  3. 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.

  4. 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.

  5. 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.

  6. Provide the authorization details from the Authorization tab.

    For information about the authorization types and required inputs, see Authorization fields.

  7. 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.

  8. 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.

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:

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:

To configure onboarding strategy to process application or subscription requests

  1. Click the menu options icon from the title bar and click Administration.

  2. Select Onboarding.

  3. From the Application/subscription onboarding section, enable any or all of the required strategies:

  4. Use the arrow keys next to these strategies to change their order. The strategies are followed by the order they appear.

  5. Click Save.

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

Next steps:

Creating an application

You must create applications to invoke protected APIs.

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

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

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

    The list of applications appear.

  2. Click Create application.

  3. Select Provider1 from the Stage list.

  4. Select Petstore from the Select API field.

  5. Provide app1 in the Name field.

  6. Select the required callback URL of the provider.

  7. Click Save.

    The application is created.

Next steps:

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.

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:

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

  2. In the API details page, click the request application icon .

Note
The request application icon appears only for the protected APIs.
  1. 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.

  2. Provide the application name and description.

  3. Click Save.

    The application is created.

Next steps:

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

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

  2. 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.

  3. Provide the application name and description.

  4. Click Save.

    The application is created.

Next steps:

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:

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:

To add the asset type with the specified details

  1. Click the menu option icon from the title bar and click Administration.

  2. Click Manage asset types.

  3. Click Add type.

  4. Provide Microservice in the Name field.

  5. Provide a description in the Description field.

  6. 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.

  7. Click Save.

    The asset type is added.

Alternative steps

Next steps

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

  1. Click the menu option icon from the title bar and click Administration.

  2. Click Manage assets.

  3. Click Microservice.

  4. Click Add Microservice.

  5. 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.

  6. 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.

  7. Click Save.

Next steps

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

  1. Click the menu option icon from the title bar and click Administration.

  2. Click the customize icon next to the active theme.

  3. Select Pages and click Add.

  4. From the Add page screen that appears, select Asset gallery page.

  5. Click Next.

  6. Select Microservice from the Select the asset field.

  7. Click Create.

    The asset gallery is added to the list of pages.

  8. Click Add to add the asset detail page.

  9. From the Add page screen that appears, select Asset details page.

  10. Click Next.

  11. Select Microservice from the Select the asset field.

  12. Click Create.

    The asset details is added to the list of pages.

Next steps

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:

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

  1. Click the menu options icon from the title bar and click Administration.

  2. Click General.

  3. Turn the Enable lifecycle slider on.

  4. 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

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

  2. Click the change state icon icon next to the API1.

  3. Select Live.

  4. 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:

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

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

  2. Click the change state icon icon next to API1.

  3. Select Draft.

  4. 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:

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

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

  2. Click the change state icon icon next to the API1.

  3. Select Retired.

  4. Click Save.

    The state of API is changed to Retired.

Next steps:

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

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

  2. Click the change state icon icon next to the package.

  3. Select Live.

  4. 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:

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

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

  2. Click the change state icon icon next to the package.

  3. Select Draft.

  4. 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:

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

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

  2. Click the change state icon icon next to the package.

  3. Select Retired.

  4. Click Save.

    The state of package is changed to Retired.

    You cannot move the retired packages to the other states.