The Kong Konnect team recently launched the Portal Management API, which allows users to manage their Developer Portals with one API. That means you can easily manage your portal settings, appearance, application registrations, and registration settings easier than before.
In this blog, I’ll walk you through two scenarios that we expect the portal management API can help streamline:
Manually approving developer applications is OK when there are one or two per week, but when you’re running at scale, this very quickly becomes painful. It’s more than just clicking the approve button. Managing developers means ensuring they’re onboarded, approved, and delegated proper permissions in a timely fashion.
The permissions aspect is key. Developers should only see the APIs that they’re contractually entitled to. However, applying permissions manually is time consuming and error prone. Let’s develop automation around the new portal management API so that we can approve trusted partners and assign them to teams at scale.
To accomplish this we’ll take the following steps:
You can see the entire script we’re using here to process newly registered developers.
The API provided by the Portal Management API returns data in the following format:
We call the GET /portals/{portalId}/developers endpoint in the get_newly_registered_developers() function, which returns a list of pending developers.
At this point, we want to auto-approve the developers. To do this, we call the process_pending_devs function:
This function will check whether or not the developer (based on the domain of their email address) is in our trusted set of partner developers. If they are, it will approve their registration, and then assign them to the team corresponding to their email address.
The approve_developer function approves trusted developers with a call to PATCH /portals/{portalId}/developers/{developerId}:
Once the developer is approved, permissions need to be assigned so that they can consume the API. The assign_developer_to_team function updates the developer’s team mappings accordingly with a call to POST /portals/{portalId}/teams/{teamId}/developers:
In just 95 lines of code, we’ve taken a process that was time consuming and error prone and automated it with the Portal Management API.
Instead of needing to manually verify and approve new developer signups, we’re now approving any developer signups coming from trusted partner domains by running a cron job on our desired cadence.
Instead of needing to manually assign teams to said developers, we’re automatically assigning teams (and their associated product permissions) to these trusted partner developers.
Not bad for a morning’s work, right?
If you want to build on what you’ve learned today, why not try one of the following use cases?
After a week or two after having the above code in production, you realize that not all partners are using your APIs. This may be due to two factors:
Kong Konnect provides the building blocks you need to create usage reports to help identify and unblock these stuck developers. Let's build these two reports:
We want to make sure our team permissions were assigned appropriately so that our developers can create applications and register to consume our APIs. We’ll use portal management APIs to discover which developers haven’t consumed any APIs.
We’ll incorporate the following endpoints into our script:
You can find the script we’re using here. We’ll step through the relevant functions below.
1. First we get all developer applications in our get_all_apps() function with a call to GET /portals/{portalId}/applications:
2. Next, in our get_apps_no_reg() function, we filter just on applications that have 0 successful registrations (meaning they aren’t consuming any of our APIs). We’ll focus only on developers who don’t have the relevant consumer permissions in Report 1.
We determine consumer permissions per developer with two calls. First, we retrieve all teams that our developer is assigned to with GET /portals/{portalId}/developers/{developerId}/teams. We get the following response:
Next, we check the roles for those teams using GET /portals/{portalId}/teams/{teamId}/assigned-roles. We get the following response:
“API Viewer” permissions tell us that this developer can’t actually consume any of our APIs because they don’t have the “API Consumer” role. We add this developer to our “Developers needing Consume permissions” report. We loop through all of our developers to find any other developers in this situation.
Note: If we wanted to get more info on this service id (1f398e86-4d5d-490c-a447-70340b1481e3) we could call GET /api-products/{id}. This would tell us more about how many versions of this API exist, when it was created and updated, which portals it’s published to, and the API name and description.
Now we’ll create a report with developers who do have the right consumer permissions but who still haven’t registered for any API product versions in the last 48 hours since they’ve created their application. We go through the same two steps as we followed from Report 1, however this time, at the second step we’ll focus on developers who do have the right permissions.
The has_permissions check in our get_apps_no_reg() function checks for any applications that have the right permissions but haven't registered to consume any API Product versions 48 hours after being created. We add these developers to the Blocked Developers report and make a note to follow up with them. Perhaps these developers couldn’t understand our documentation. Perhaps they don’t understand our use cases for why they would want to use our APIs. Or perhaps they got a little carried away watching football and abandoned their app development. Whatever the reason is, we feel more confident knowing who they are.
There you have it! By incorporating these three endpoints into our script, we’re now able to automatically alert the relevant API Product owners to developers who may need following up with — either because they need more permissions or because they may need additional assistance. Actions like these help ensure our developers can more quickly get started and get building.
Note this was a very scoped-down example of how to manage developer permissions / notifications. If implementing in your own environment, you may want to take the following into consideration:
If you want to dive into the code, you can see the entire script we used here or read the docs.
Have any questions or additional use cases you’d like to see documented? Reach out to us on LinkedIn or X.
A developer portal is a storefront to your APIs (the products) that internal and external developers are trying to consume. The Kong Developer Portal provides a single source of truth for all developers to locate, access and consume services. With
APIs have quietly powered the global shift to an interconnected economy. They’ve served as the data exchange highways behind the seamless experiences we now take for granted — booking a ride, paying a vendor, sending a message, syncing financial rec
Bridging the API (and API access) gap between AI coding tools, agents, and the APIs that they “eat” Data might be the fuel for AI. But APIs are the proper way to package that “fuel” as AI-ready “food” is through the API. AI coding tools can do a lot
The numbers tell a compelling story. While 65% of organizations that use APIs are currently generating revenue from them, a significant gap exists between API adoption and AI readiness. 83.2% of respondents have adopted some level of an API-first ap
🚧 The challenge: Scaling GenAI with governance While building a GenAI-powered agent for one of our company websites, I integrated components like LLM APIs, embedding models, and a RAG (Retrieval-Augmented Generation) pipeline. The application was d
Efficiently managing your developer portal is critical in productizing your APIs quickly and reliably. A streamlined developer portal ensures that your APIs are easily accessible, well-documented, and secure — driving higher adoption and easier inte