The Developer Services portal acts as a client for Apigee Edge. That means the portal does not function as a stand-alone system. Instead, much of the information used by the portal is actually stored on Edge. When necessary, the portal makes an HTTP or HTTPS request to retrieve information from Edge or to send information to Edge.

Edge does not make requests to the portal, it only responds to requests made from the portal. Therefore, all interactions between the portal and Edge are initiated by the portal.

Ensuring access to Edge from the portal

Because much of the information used by the portal is stored on Edge, you must ensure that the portal can access Edge. The portal initiates communication with Edge by making REST requests over HTTP and HTTPS. For example, when a developer registers a new app on the portal, the portal makes a request to Edge to send information about the app to Edge.

Both Edge and the portal can be deployed in the cloud or on prem, and you can mix deployments types. For example, you can deploy both in the cloud, both on prem, or deploy one in the cloud and one on prem:

  • If both the portal and Edge are deployed by Apigee in the cloud, then there should be no issues in making requests from the portal to Edge.
  • If you deploy the portal on prem, then you must ensure that the portal can make requests to Edge, regardless of whether Edge is deployed in the cloud or on prem.
  • If you deploy Edge on prem, then you must ensure that the portal has access to Edge. That means your Edge server must accept requests from the portal regardless of whether the portal is deployed in the cloud or on prem.

If either Edge or the portal is deployed in the cloud, then all requests use HTTPS. If both are on-prem, and accessible only over an internal network, then requests can use HTTP.

Managing apps and API keys from the portal

When the developer completes the app registration process on the portal, the portal sends information about the app to Edge, including the app name and the API products associated with the app.

If Edge successfully registers the app, Edge returns a single API key to the portal. The developer then uses that API key to access the API products associated with the app.

No information about apps and API keys is actually stored on the portal. Instead, all of that information is stored on Edge. Therefore, any time a developer uses the portal to view information about an app, the portal makes a request to Edge to access that information. Any time the developer modifies an app, the portal automatically sends those modifications to Edge.

For example, a developer logs in to the portal and navigates to their My Apps page. To populate the My Apps page, the portal makes a request to Edge to retrieve information about the developer's apps and API keys. That information then appears on the developer's My Apps page in the portal:

If the developer then adds, removes, or modifies an app, the portal sends those modifications to Edge.

Because all information about apps and API keys is stored on Edge, an Edge administrator can manipulate that information by using the Edge UI. For example, an administrator can:

  • Add, remove, or modify a developer's app
  • Revoke or approve an API key for an app

Shown below is the same app, the 'My Weather App', as it appears to an administrator on the Edge UI:

 

Managing developers from the portal

When a developer registers as a new portal user, the developer is created on Edge and on the portal. Therefore, unlike apps and API keys, information about developers is actually stored on both Edge and the portal.

The developer information stored on Edge includes:

  • First name
  • Last name
  • Email address
  • Optional additional information sent from the portal

The email address is the primary key used by Edge to identify the developer. Therefore, all developers have a unique email address on Edge.

The portal stores the same information as Edge, but it also stores additional information, including:

  • Portal password
  • Portal account status: active or blocked
  • Portal role: authenticated user, administrator, other
  • Role based permissions: determine the actions the developer is allowed to perform on the portal

When a developer logs in to the portal, it is the portal that is responsible for authenticating the developer and for enforcing role-based permissions.

Because the portal stores all of the information about a developer, consider the portal as the system of record for developer information, not Edge. When the developer modifies their information on the portal, that information is stored on the portal and, if applicable, sent to Edge. For example, if the developer changes their first name, that information is sent to Edge. But if the developer changes their password, that information is only stored locally on the portal.

For more information, see Add and manage user accounts.

Synchronizing changes made to a developer on Edge with the portal

Edge does not initiate communication with the portal. If you, as an Edge administrator, manipulate information about a developer in the Edge UI, there is no guarantee when that information will be pushed down to the portal. Therefore, use the administration features of the portal to create, modify, and delete developers, not Edge.

A portal administrator can force a sync between the portal and Edge to download information to the portal from Edge. However, if you only modify developers on the portal and not on Edge, you should never have to perform this sync. Additionally, because Edge does not let you set a password when you create a developer, any developer created on Edge has their portal password set to a random value. Therefore, the developer must go through the password recovery process before they can log in to the portal.  

For more information, see Adding developers to your organization.

Help or comments?

  • Something's not working: See Apigee Support
  • Something's wrong with the docs: Click Send Feedback in the lower right.
    (Incorrect? Unclear? Broken link? Typo?)