You're viewing Apigee Edge documentation.
Go to the
Apigee X documentation. info
There are several concepts that are common ideas with a unique meaning in Apigee.
| Term | Definition |
|---|---|
| API | A proxy that acts as a facade for your existing API. Rather than calling your existing API, developers begin calling the new API generated by Apigee. This facade decouples your public interface from your backend API, shielding developers from backend changes, while enabling you to innovate at the edge without impacting your internal development teams. As you make backend changes, developers continue to call the same API uninterrupted. In more advanced scenarios, Apigee lets you expose multiple interfaces to the same API, freeing you to customize the signature of an API to meet the needs of various developer niches simultaneously. |
| API base path and resources | An API is made up of base path and a set of resources (also known as resource paths). For each API, you define a single root URL and multiple resource paths. You can think of an API simply as a set of URIs, all of which share a common base path. To make it easier to manage your APIs, Apigee augments these raw URIs with display names and descriptions. |
| API consumer | Synonymous with "app developer," who uses the APIs created by an API provider. |
| API developer | A software engineer in an API provider organization who builds APIs. Those APIs are used by app developers (API consumers) to build apps. |
| API package | A collection of API products that are presented to developers as a bundle, and typically associated with a rate plan. |
| API product | A collection of API resources (URIs) combined with a service plan and presented to developers as a bundle. The API product can also include some metadata specific to your business for monitoring or analytics. One or more resources can be monetized by including them in an API product, which can then bundled into an API package for monetization. |
| API provider | An API provider build APIs (using Edge) for API consumers (app developers) to use. |
| app developer | In Edge, app developers register their apps with an API provider, which is how app developers get the API keys they need to call the provider's API proxies. |
| apps | Your developers use apps to access the resources in your API products. When you create an app, you select the API product to include, and Apigee generates a key. Each app has a single key that provides access to multiple API products. Apps allow you to control who can access your resources. You can control who has access to your API products by revoking and refreshing an app's key. And you can control access to bundles of resources by revoking or deleting access to the products in an app. |
| balance details | For a prepaid developer, the balance in the developer's account. |
| closed adjustment | An adjustment that has been applied in published billing documents. |
| closed billing month | A complete calendar month for which billing documents have been published. |
| custom limit | A limit (such as a limit on the number of transactions on an API product) that you can explicitly set up using monetization. Also called an explicit limit. |
| developer category rate plan | A rate plan that applies to all developers in a specific category and is available for purchase by all developers in that category. |
| developer rate plan | A rate plan that applies to a specific developer and is available for purchase only by that developer. |
| disclosed agent | In commercial law, a person who is authorized to act on behalf of another (called the principal) to create a legal relationship with a third party. In monetization, a tax model can be set up for a shared revenue plan such that the API provider acts as a disclosed agent of the developer to collect revenue (and possibly sales taxes) on behalf of the developer. |
| disclosed tax model | A tax model in which the API provider acts as a disclosed agent of the developer. |
| environment | A runtime execution context for APIs. An API must be deployed to an environment before it can be accessed at runtime. By default, Apigee organizations are provisioned with two environments: 'test' and 'prod'. The 'test' environment is typically used for deploying APIs undergoing testing. The 'prod' environment is typically used for deploying APIs for production use. |
| hybrid tax model | A tax model in which the API provider acts as a disclosed agent of the developer. However, the API provider pays the sales tax collected from their subscribers to the local tax authorities on the developer’s behalf. |
| implicit limit | A limit (such as a developer prepaid balance limit) set by monetization. |
| monetization | A component of the Apigee Edge Developer Services that provides an easy-to-use and flexible way of monetizing API products. |
| monthly amount used | A developer's total usage for a given month, which includes setup fee + transaction fee + recurring fee. |
| monthly payments | The recurring payments made by a developer based on the plans purchased. Rate plans can have recurring fee that is charged to a developer every month regardless of usage. |
| netting statement | A financial document that shows the net balances between invoices and revenue share statements. |
| open adjustment | An adjustment that has not yet been applied in published billing documents. |
| open billing month | A complete calendar month for which “final” billing documents have not been published. |
| organization | A container for all the objects in your Apigee account, including APIs, API products, API packages, apps, and developers. A user account is required for each organization for which you may be a member. (Most users will have an account in only one organization.) You need to supply your credentials (username and password) and the name of your organization with each API request you submit. |
| package catalog | A list of API packages. Each package is listed with its API products and rate plans. |
| prepaid balance | An amount of money available for a prepaid developer to pay in advance for API packages. |
| prepaid developer | A developer who pays in advance for the use of an API product. Funds are deducted from a prepaid developer's balance when the API product is used. The developer must maintain a prepaid balance sufficient to purchase the API product. Developers are assigned prepaid or postpaid status by the API provider. |
| policy | A processing step that executes as an atomic, reusable unit of logic within an API flow. Typical policies include routing requests to the proper endpoint, transforming a message format, enforcing access control, calling remote services for additional information, masking sensitive data from external users, examining message contents for potential threats, caching common responses to improve performance, and so on. Policies may be conditionally executed based on the content or context of a request or response message. For example, a transformation policy may be executed to customize a response format if the request message was sent from a smartphone. |
| postpaid developer | A developer who is billed monthly (through an invoice) for the use of API products. The developer pays for the use of API products based on the payment terms set by the plan(s) included on the invoice. Developers are assigned postpaid or prepaid status by the API provider. |
| price points | A range of possible prices at which something might be marketed. |
| rate card rate plan | A rate plan in which the developer is charged a fixed or variable rate for each transaction involving a monetized API product. |
| rate plan | A specification of the fees, other charges, and revenue share for the use of API products offered in a monetized API package. |
| resource path |
A RESTful concept, a resource path is a uniform resource identified (URI) that identifies the network path to a given resource. |
| revenue share rate plan | A rate plan in which a percentage of the revenue generated from each transaction involving a monetized API product is shared with the developer of the app issuing the request. |
| revenue share and rate card plan | A rate plan in which a percentage of the revenue generated from each transaction involving a monetized API product is shared with the developer of the app issuing the request. The developer is also charged a fixed or variable fee for each transaction. |
| self-billing invoice | A financial document that is generated instead of a revenue share statement. It details the amount due to the developer, and acts as an invoice to the API Provider on behalf of the developer. |
| standard rate plan | A rate plan that is available for purchase by all developers. |
| tax | Total tax applied to a developer's usage and fees. |
| top up | The action taken by a prepaid developer to add funds to the prepaid balance. |
| transaction recording policy | A mechanism that enables monetization to capture transaction parameters and custom attributes. Monetization needs this information to perform its monetization processing, such as applying rate plans to API requests and responses based on the custom attributes captured in each transaction. |
| undisclosed agent | An organization (or operator) that takes part in the underlying supply of applications, such that it is deemed to purchase the content on behalf of the developer (for tax purposes only). As an undisclosed agent, the organization (or operator) can collect and account for taxes due from end users. This status is only relevant for tax purposes — the legal status of the developer in the supply chain is unaffected. |
| undisclosed tax model | A tax model in which the API provider deducts the tax collected from the end users and pays it to the local tax authorities. |
| version | The version of the developer-facing API interface. For example, pivotaltracker.com/services/v3, or api.enterprise.apigee.com/v1. (This term is distinguished from ‘revision’, which is the numbered, version-controlled package of configuration and policies bundled into an API Proxy. In short, API interfaces have versions, while API Proxies have revisions. |