Register app developers

Register and manage your app developers, as described in the following sections. (App registration is a separate process, as described in Register apps and manage API keys).

Introduction

Edge provides many benefits that are completely dependent on knowing who's calling your APIs. For example, API security, traffic management, and a fair amount of analytics data depend on knowing who's calling. And how does Edge know who's calling your APIs? By reading unique information in each API call, such as a user ID, an API key, or an OAuth token. That unique information locks or unlocks the functionality you build into your API proxies, giving you full control over API access and behavior.

That's why app developers need to register to use your APIs. Once added, developers register their apps, choose the APIs they want to use, and receive the unique API credentials (consumer keys and secrets) needed to access your APIs.

How to register app developers

Register app developers using one of the following methods:

Recommendations for managing app developers on Drupal-based developer portals

If you use the Drupal-based developer portal, Apigee recommends that you manage app developers directly on your portal, not using Edge. Managing developers directly on the developer portal provides the following advantages:

  • When you add a developer through the administrator interface on the portal, you can set the developer's password for the portal and trigger an automated email message sent to the developer.

    When adding or modifying a developer using Edge, no email is sent to the developer and you cannot set the password for the developer on the portal. Therefore, the developer must reset their password on the portal before they can sign in to the portal.

  • Any changes made to the developer's account on the portal are automatically sent to Edge.

If you decide to manage app developers using Edge, you must synchronize app developers between the portal and Edge.

Exploring the Developers page

Access and explore the Developers page using the Edge UI and Classic Edge UI.

Edge UI

To access the Developers page:

  1. Sign in to apigee.com/edge.
  2. Select Publish > Developers in the left navigation bar.

The Developers page is displayed.

As highlighted in the figure, the Developers page enables you to:

Classic Edge UI

To access the Developers page:

  1. Sign in to enterprise.apigee.com.
  2. Select Publish > Developers in the top navigation bar.

The Developers page is displayed.

Adding a developer

To add a developer:

  1. Access the Developers page.
  2. Click + Developer.
  3. Enter the developer details, including first name, last name, email, and username.
  4. Click Create.

Viewing and editing developer details

View and edit developer details. For Monetization-enabled organizations, you can edit the monetization custom attributes defined in Configuring monetization attributes.

To view and edit developer details:

  1. Access the Developers page.
  2. Click the row of the developer that you want to view and edit to expand the details.
  3. In the Details section, the following information is displayed. Edit the developer details, as required.
    Detail Description
    Details Developer first and last name, username, and email; registration status and duration; and developer ID.
    To edit the developer details, click within any of the following fields:
    • First Name
    • Last Name
    • Email
    • Username
    Modify the content and press Enter to confirm the change.
    Custom attributes Custom attributes defined for the developer. Configure custom attributes, as required. For more information, see:
    Apps Apps that have been registered by the developer. See Registering apps.
  4. Activate or deactivate the developer in the Status field.
    For more information, see Activating and deactivating a developer.

Core Persistence Services caching minimum: In organizations with Core Persistence Services (CPS) enabled (currently Apigee Public Cloud only), Edge keeps the following entities in cache for a minimum of 180 seconds after the entities are accessed.

  • OAuth access tokens. This means the ExpiresIn element on the OAuth v2 policy won't be able to expire an access token in less than 180 seconds.
  • Key Management Service (KMS) entities (Apps, Developers, API Products).
  • Custom attributes on OAuth tokens and KMS entities.

Managing custom attributes for a developer

Add up to 18 custom attributes for each developer, including the monetization attributes described in Configuring monetization attributes.

To manage custom attributes:

  1. Access the Developers page.
  2. Click the row of the developer for which you want to manage custom attributes to expand the details.
  3. Click + in the Custom Attributes section.
  4. Enter the attribute name and value.
  5. Click .
  6. To delete a custom attribute, position your cursor over the attribute and click in the actions menu.

Activating and deactivating a developer

When an app developer self-registers in your portal, you can configure whether or not they are active by default.

When a developer is inactive, the developer can still sign in to the developer portal and create apps, but none of the corresponding API keys will work. The developer's apps still retain their approved (or other) status, as do the API keys, even though they're not valid while the developer is inactive.

To activate or deactivate a developer:

  1. Access the Developers page.
  2. Click the row of the developer that you want to activate or deactivate to expand the details.
  3. In the Details section, set the Status field to Active or Inactive, as required.
  4. Repeat the steps if the developer is in multiple organizations.

Exporting publishing data

Export the following publishing data as a comma-separated values (CSV) file:

  • Developer details
  • Developer, application, and API product details

To export publishing data:

  1. Access the Developers page.
  2. Click Export CSV...
  3. Select Developers or Developers, Apps, and Products from the drop-down.

The selected publishing data is downloaded as a CSV file.

Deleting a developer

To delete a developer:

  1. Access the Developers page.
  2. Position your cursor over the row of the developer that you want to delete to display the actions menu.
  3. Click .
  4. Click Delete to confirm the deletion.

Synchronizing app developers between the portal and Edge

If you are using a Drupal-based developer portal to publish your APIs, changes made to app developers using Edge are not propagated to the portal. You must sign in to the portal as a portal administrator and synchronize the portal with Edge for those changes to appear on the portal.

To synchronize your developer portal with the app developers defined on Edge, refer to the following sections:

Grouping developers into companies

With monetization, a company is a collection of developers managed as a single entity. A company can be any grouping that is appropriate to your organization such as business unit, product line, or division. Grouping developers into companies is useful when your need to have multiple developers associated under a single corporate entity. For example, you may need to set up different companies for billing purposes. However, developers in your organization don't need to be associated with a company. Note that a developer is always a single entity, uniquely identified by the email element. If a developer is part of a company you'll see the Company name on the Developers page.

For more information about managing companies and developers for monetization, see Manage companies and developers.

Configuring monetization attributes

When editing a developer using the UI or creating or editing a developer using the API, you can configure the monetization properties defined in the following table. Initially, you configure the monetization properties for the organization when editing the organization profile.

Field name Custom attribute name Description
Address MINT_DEVELOPER_ADDRESS

Address of the developer, including the following fields: Address (lines 1 and 2), City, State, Zip Code, and Country.

Note: The address is required if the developer is not grouped with a company and wants to subscribe to a published rate plan.

Billing Profile MINT_BILLING_PROFILE

Billing cycle for your organization. Valid values include:

  • PRORATED: Billing is based on the number of days that an API product is used in a calendar month.
  • CALENDAR_MONTH: Billing is done monthly.
Billing Type MINT_BILLING_TYPE

Developer payment model used for billing. The value can be one of the following:

  • PREPAID: Developer pays in advance for the use of an API product. Funds are deducted from the developer's balance when the API product is used. The developer must maintain a prepaid balance sufficient to purchase the API product.
  • POSTPAID: Developer 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.
  • BOTH: Supports either billing type. Defaults to PREPAID.

See Configuring prepaid and postpaid billing types.

Category MINT_DEVELOPER_CATEGORY Developer category to which you want to add the developer. A developer category is a grouping of developers or companies with similar characteristics. For more information, see Manage developer categories.
Company ID MINT_COMPANY_ID Company ID, if applicable. For more information, see Grouping developers into companies.
Developer Type MINT_DEVELOPER_TYPE This property is not used by Apigee.

Developer type. Valid values include: TRUSTED or UNTRUSTED

Is Broker MINT_IS_BROKER Flag that specifies whether the revenue is based on net.
Legal name MINT_LEGAL_NAME Legal name of the developer that will be used in all reports.
Note: This attribute is required if the developer is not grouped with a company and wants to subscribe to a published rate plan.
Self Billing MINT_HAS_SELF_BILLING Flag that specifies whether self-billing invoices are enabled. If enabled (true), monetization generates a self-billing invoice instead of a revenue share statement. A self-billing invoice is a financial document that details the amount due to the developer. It acts as an invoice to the API Provider on behalf of the developer.
Tax Exempt Auth # MINT_TAX_EXEMPT_AUTH_NO Government tax exemption number, if applicable.
Tax Rate MINT_APPROX_TAX_RATE Approximate tax rate for the developer. Specify a decimal value with a maximum number of 3 characters before the decimal and 4 characters after the decimal.

Managing developers using the API

Manage developers using the Developer APIs.

When creating and updating a developer using the API, you can configure the monetization attributes described in Configuring monetization attributes, as required.