Publishing overview

This page applies to Apigee and Apigee hybrid.

View Apigee Edge documentation.

Publishing is the process of making your APIs available to app developers for consumption.

Video: The following video provides a high-level introduction to API publishing.

Publishing APIs involves the following tasks, described in this topic:

  1. Create the API products that bundle your APIs.
  2. Register app developers.
  3. Register developer apps.
  4. Provide documentation and community support for your APIs.

Task 1: Create an API product

The first task in publishing is to create an API product. An API product is a collection of API resources that are offered as a package to app developers for consumption. Create API products by using the Apigee API or UI. (See What is an API product? to learn more about API products.)

A left-to-right sequence diagram showing a developer, an app, APIs,
    and backend services. The API icon and resources are highlighted. A dotted line
    points from the developer to an icon of an app the developer has built. Arrows from and
    back to the app show the request and response flow to an API icon, with an app key positioned
    above the request. The API icon and resources are highlighted. Below the API icon are two sets
    of resource paths grouped into two API products: Location product and Media product.
    The Location product has resources for /countries, /cities, and /languages, and the Media
    product has resources for /books, /magazines, and /movies. To the right of the API are the
    backend resources the API is calling, including a database, an enterprise service bus, app
    servers, and a generic backend.

In this figure, the API consists of two products, each containing three API resources.

As an API provider, you are responsible for building the APIs and API products to handle access control, usage restrictions, and any other business requirements. For example, you might:

  • Release a free API product that allows read-only access to its API resources.
  • Release a second API product for a low price that allows read/write access to the same API resources as the free version but with a low access limit, such as 1000 requests per day.
  • Release a third API product for a higher price that allows read/write access the same API resource but with a high access limit.

The important thing to remember is that Apigee gives you the flexibility to create API products that match the business requirements of your APIs.

For more information on creating API products, see Managing API products.

Task 2: Register an app developer

A developer creates the apps that consume your APIs. An app developer registers on Apigee before they can register their app. When they register their app, they receive an API key that will give the app access to the API.

Through the app registration process, you control who has access to your APIs. At any time, you can delete an app developer, which invalidates all API keys associated with that developer, therefore denying that developer access to your APIs.

A left-to-right sequence diagram showing a developer, an app, APIs,
    and backend services. The developer icon is highlighted. A dotted line points from the
    highlighted developer to an icon of an app the developer has built. Arrows from and
    back to the app show the request and response flow to an API icon, with an app key positioned
    above the request. Below the API icon are two sets
    of resource paths grouped into two API products: Location product and Media product.
    The Location product has resources for /countries, /cities, and /languages, and the Media
    product has resources for /books, /magazines, and /movies. To the right of the API are the
    backend resources the API is calling, including a database, an enterprise service bus, app
    servers, and a generic backend.

As an API provider, you decide how to register developers. For example, you can use a manual registration process that requires a potential developer to contact your organization to register. The potential developer must supply all necessary information, such as an email address, first and last name. If you approve the developer’s request, you can use the Apigee UI to manually register the developer. See Registering app developers for more.

Task 3: Register a developer app

Before an app can access your APIs, the app must be registered. However, only a registered developer can register an app.

A left-to-right sequence diagram showing a developer, an app, APIs,
    and backend services. The app, request/response, and API key arrows are highlighted. A dotted
    line points from the developer to an icon of an app the developer has built. Arrows from and
    back to the app show the request and response flow to an API icon, with an app key positioned
    above the request. The API icon and resources are highlighted. Below the API icon are two sets
    of resource paths grouped into two API products: Location product and Media product.
    The Location product has resources for /countries, /cities, and /languages, and the Media
    product has resources for /books, /magazines, and /movies. To the right of the API are the
    backend resources the API is calling, including a database, an enterprise service bus, app
    servers, and a generic backend.

At the time of app registration, the developer selects one or more API products. For example, you might publish multiple API products corresponding to different types of services and pricing plans. The app developer can then pick and choose from the list of available API products.

In response to registering the app on Apigee, Apigee assigns a unique API key to the app. The app must pass that API key as part of every request to an API resource. The key is authenticated and, if valid, the request is granted. At any time, you as the service provider can revoke the key so that the app can no longer access your APIs.

As an API provider, you decide how you want to register apps. You could:

  • Use a manual process that requires a developer to contact your organization to register their app. In response, you would send the developer the API key, possibly by email.
  • Use the Apigee API to integrate app registration functionality and key delivery into your website.
  • For a paid Apigee account, use the Apigee Developer Services portal which has built in support for app registration and API key delivery.

For more information, see Registering apps and managing API keys.

Task 4: Document your APIs

An important consideration for publishing API products is providing documentation and a developer feedback mechanism. Developer portals with social publishing features are increasingly being used for communication with the development community. This includes communicating static content, such as API documentation and terms-of-use, as well as dynamic community-contributed content such as blogs and forums, as well as customer support features.

A left-to-right sequence diagram showing a developer, an app, APIs,
    and backend services. The developer icon is highlighted. Below the developer is a box that
    represents a developer portal. The portal contains API documentation, samples, tutorials,
    API reference, and other. The portal also contains blogs, forums, and a support portal.
    A dotted line points from the highlighted developer to an icon of an app the developer has
    built. Arrows from and back to the app show the request and response flow to an API icon,
    with an app key positioned above the request. Below the API icon are two sets
    of resource paths grouped into two API products: Location product and Media product.
    The Location product has resources for /countries, /cities, and /languages, and the Media
    product has resources for /books, /magazines, and /movies. To the right of the API are the
    backend resources the API is calling, including a database, an enterprise service bus, app
    servers, and a generic backend.

You can build your own website to deploy your documentation or, if you have a paid Apigee account, you can use the Apigee Developer Services portal. The portal has built-in support for documentation, blogs, forums, and other types of content required to support your developer community.

SmartDocs lets you document your APIs on the Developer Services portal in a way that makes the API documentation fully interactive. Interactive documentation with SmartDocs means portal users can:

  • Read about the API
  • Send a live request to the API
  • View a live response returned from the API

For more information, refer to the following sections: