You can use a routing policy to define an external route where the consumers of your APIs will make requests. Then, after these requests reach 3scale, you define where they are delivered.

For example, consider that you have a book API available at http://books.mystore.com/. You want your clients to consume your API through 3scale to be able to manage different aspects of the API. Consider also that you define a 3scale route /books, which is the public external route that your clients will use. With the routing capabilities of 3scale, you can map the /books route to your external service http://books.mystore.com/. The following diagram illustrates this process.

Figure 1.2: API Manager routing example

To create routing policies, 3scale provides two abstractions: products and backends. A product is used to define the external routes accessible by your clients. A backend is used to define your API services. Then, a product is mapped to one or several backends to achieve the routing policy. The following diagram illustrates the books example with a new route, /authors. The /books route is mapped to http://books.mystore.com/ and the /authors route is mapped to http://authors.mystore.com/.

Figure 1.3: API Manager routing example based on products and backends

Both products and backends are covered later in this course.

You can use rate limits to control the number of requests that each of your clients can make to your APIs.

3scale provides the abstraction of an application. You can consider that each of your clients is a 3scale application. On every request, 3scale must identify which of your clients (i.e. applications) is making the request to be able to apply the rate limits. Every application is assigned a random user key. Then, your client must include this user key on every request.

At the same time, an application holds an application plan, which is used to define the rate limits for every application.

For example, consider the books example previously mentioned. If you have two clients, client1 and client2, then you can create two applications. For every application, a random user key is generated, which must be provided when making external requests. For every application, you can create an application plan, which contains the rate limits of the application (i.e. how many requests the application can make in a specific period of time). The following diagram illustrates this behavior.

Figure 1.4: Routing limits example

Applications and application plans are covered later in this course.

The Developer Portal is a public web page that you can use to provide information about your APIs. The Developer Portal is entirely customizable and it provides features such as Swagger definitions importing, authentication for developers, or email templates.

Figure 1.5: Screenshot of the default Developer Portal

The Developer Portal is covered later in this course.

In the context of 3scale API Management, a tenant acts as an instance of 3scale. Within the same 3scale installation, you can create several instances of the product.

By using several tenants, you can create a logical separation of your APIs. For example, consider that you have two tenants: orders and finance. In the order tenants you create APIs related to orders, and in the finance tenant you create APIs related to payments. At the same time, you can restrict who has access to every tenant independently.

The default tenant is called 3scale, and you can create as many tenants as you want depending on your needs.

Tenants are covered later in this course.