This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
Accept
Reject
Preferences
Log in to ask a question
Log in to ask a question

Integrated Developer Portal for APIGEE X

Posted on 02-26-2024 07:30 PM
NikhilAnand_whp
Bronze 5
Bronze 5
Reply posted on --/--/---- --:-- AM

Hi,

We are currently utilizing an integrated developer portal solution on the APIGEE X platform.

We have two separate organizations, one dedicated to production (prod) and the other to non-production (non-prod) environments. Consequently, we have implemented two distinct integrated portals for each organization.

As a result of this configuration, our clients are required to register and create an application twice for the same API, once on each portal. This duplication process detracts from the optimal user experience. Ideally, we seek a unified portal where controls, such as approval processes for prod and non-prod, and distinct credentials for each environment, can be managed centrally.

Is there a way, we can connect our integrated portal to both the org. (prod and non-prod) ? If this integration is not feasible, will drupal portal provide this feature.

In the event that Drupal does not support this functionality, what are my options. ? Are there any relevant reference documents or links that could offer insights into addressing this requirement?

@dchiesa1 @matt-google @kurtz @kurtkanaskie - Much appreciated, if you can have a look

2 1 129
1 REPLY 1

Posted on --/--/---- --:-- AM
kurtkanaskie
Staff
Reply posted on --/--/---- --:-- AM

Currently the Integrated Portal can only connect to a single org. I've heard that Drupal can be customized to work with multiple orgs, but I have not tried.

Regarding "our clients are required to register and create an application twice for the same API, once on each portal.", why are the required?

Are they interested in early adopters / contributors of non-prod APIs, if so, keeping them separate is good.

If they are seeking to adopt a next version of the API, that could be published on the prod portal as beta or v2 of the API.

If you want to provide a "sandbox" for developers to try your APIs, then I'd recommend a "sandbox" environment on your prod org and offer API Products for both "sandbox" and "prod" versions. It's common for the "sandbox" API to have a mock backend or use fake accounts and IDs (e.g. for credit cards).

Hope that helps.