The Kong Konnect team recently launched the [Portal Management API](https://docs.konghq.com/konnect/api/portal-management/latest/)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](https://github.com/c3pko/portal-management-v2-examples)here to process newly registered developers.
The API provided by the Portal Management API returns data in the following format:
{
"data": [
{
"created_at": "2023-08-03T23:45:50.042Z",
"updated_at": "2023-08-03T23:45:50.042Z",
"id": "b5f13fcb-190f-4418-a051-79c163770050",
"email": "peter@arsenal.com",
"full_name": "Arsenal",
"status": "pending",
"application_count": 0
},
{
"created_at": "2023-08-22T22:22:12.708Z",
"updated_at": "2023-08-22T22:22:12.708Z",
"id": "6084e049-3a1d-4b62-89a0-970750082016",
"email": "andrea@intermilan.com",
"full_name": "Andrea",
"status": "pending",
"application_count": 1
},
{
"created_at": "2023-10-25T00:04:11.286Z",
"updated_at": "2023-10-25T00:05:15.291Z",
"id": "15075e88-bb30-437a-9d0b-64f1aec8cd0e",
"email": "mike@aol.com",
"full_name": "Mike",
"status": "pending",
"application_count": 0
}
...
],
"meta": {
"page": {
"total": 6,
"size": 100,
"number": 1
}
}
}We call the [GET /portals/{portalId}/developers](https://docs.konghq.com/konnect/api/portal-management/latest/#/Portal%20Developers/list-portal-developers)GET /portals/{portalId}/developers endpoint in the [get_newly_registered_developers()](https://github.com/c3pko/portal-management-v2-examples/blob/main/map-new-devs-to-teams.py#L32-L49)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](https://github.com/c3pko/portal-management-v2-examples/blob/main/map-new-devs-to-teams.py#L84-L92)process_pending_devs function:
def process_pending_devs(pending_developers):
for developer_id in pending_developers:
domain = pending_developers[developer_id]
if domain in mapped_teams:
# first approve their signup
approve_developer(developer_id)
# then assign them to the appropriate team (can also do this in a batch, per team)
team_id = email_to_team_mapping[domain][1]
assign_developer_to_team(developer_id, team_id) 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](https://github.com/c3pko/portal-management-v2-examples/blob/main/map-new-devs-to-teams.py#L64-L71)approve_developer function approves trusted developers with a call to [PATCH /portals/{portalId}/developers/{developerId}](https://docs.konghq.com/konnect/api/portal-management/latest/#/Portal%20Developers/update-developer)PATCH /portals/{portalId}/developers/{developerId}:
def approve_developer(id):
try:
url = base_url + "/portals/" + portal_id + "/developers/" + id
payload = {"status": "approved"}
response = requests.request("PATCH", url, json=payload, headers=headers)
print(response.text)
except Exception as e:
print("Error approving developer:", id, e)Once the developer is approved, permissions need to be assigned so that they can consume the API. The [assign_developer_to_team](https://github.com/c3pko/portal-management-v2-examples/blob/main/map-new-devs-to-teams.py#L74-L81)assign_developer_to_team function updates the developer’s team mappings accordingly with a call to [POST /portals/{portalId}/teams/{teamId}/developers](https://docs.konghq.com/konnect/api/portal-management/latest/#/Portal%20Team%20Membership/add-developer-to-portal-team)POST /portals/{portalId}/teams/{teamId}/developers:
def assign_developer_to_team(dev_id, team_id):
try:
url = base_url + "/portals/" + portal_id + "/teams/" + team_id + "/developers"
payload = {"id": dev_id}
response = requests.request("POST", url, json=payload, headers=headers)
print(response.text)
except Exception as e:
print("Error assigning developer", dev_id, "to team", team_id, e)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](https://github.com/c3pko/portal-management-v2-examples/blob/main/developers-to-follow-up-with-report.py)here. We’ll step through the relevant functions below.
1. First we get all developer applications in our [get_all_apps()](https://github.com/c3pko/portal-management-v2-examples/blob/main/developers-to-follow-up-with-report.py#L32-L44)get_all_apps() function with a call to [GET /portals/{portalId}/applications](https://docs.konghq.com/konnect/api/portal-management/latest/#/Portal%20Applications/list-applications)GET /portals/{portalId}/applications:
def get_all_apps():
try:
url = base_url + "/portals/" + portal_id + "/applications"
response = requests.get(url, headers=headers)
if response.status_code == 200:
return response.json()["data"]
else:
print("Error:", response.status_code)
return []
except Exception as e:
print(f"Error in get_all_apps: {e}")
return []2. Next, in our [get_apps_no_reg()](https://github.com/c3pko/portal-management-v2-examples/blob/main/developers-to-follow-up-with-report.py#L81-L125)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](https://docs.konghq.com/konnect/api/portal-management/latest/#/Portal%20Team%20Membership/list-portal-developer-teams)GET /portals/{portalId}/developers/{developerId}/teams. We get the following response:
{
"meta": {
"page": {
"number": 1,
"size": 10,
"total": 1
}
},
"data": [
{
"id": "d3874c1b-2fc7-4d0e-9d58-1ce5307ec1d2",
"name": "Inter Milan",
"description": "Inter Milan Team's API",
"created_at": "2023-11-14T18:06:57Z",
"updated_at": "2023-11-14T23:00:37Z"
}
]
}Next, we check the roles for those teams using [GET /portals/{portalId}/teams/{teamId}/assigned-roles](https://docs.konghq.com/konnect/api/portal-management/latest/#/Portal%20Team%20Roles/list-portal-team-roles)GET /portals/{portalId}/teams/{teamId}/assigned-roles. We get the following response:
{
"meta": {
"page": {
"number": 1,
"size": 10,
"total": 1
}
},
"data": [
{
"id": "30f1f1c6-f55f-48c3-90bc-0fb62b07356b",
"role_name": "API Viewer",
"entity_region": "us",
"entity_type_name": "Services",
"entity_id": "1f398e86-4d5d-490c-a447-70340b1481e3"
}
]
}“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}](https://docs.konghq.com/konnect/api/api-products/latest/#/API%20Products/get-api-product)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](https://github.com/c3pko/portal-management-v2-examples/blob/main/developers-to-follow-up-with-report.py#L103-L121)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](https://github.com/c3pko/portal-management-v2-examples)here or read the [docs](https://docs.konghq.com/konnect/api/portal-management/latest/)docs.
Have any questions or additional use cases you’d like to see documented? Reach out to us on [LinkedIn](https://www.linkedin.com/company/konghq/)LinkedIn or [X](https://twitter.com/thekonginc)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
[](https://konghq.com/blog/engineering/customize-kong-developer-portal)
The goal of Integration Platform as a Service (iPaaS) is to simplify how companies connect their applications and data. The promise for the first wave of iPaaS platforms like Mulesoft and Boomi was straightforward: a central platform where APIs, sys
[](https://konghq.com/blog/engineering/kong-and-polyapi)
MCP is an open standard that defines how AI clients communicate with remote servers. It provides a standardized protocol for clients like Claude, Cursor, or VS Code to access tools, resources, and capabilities from external systems. Currently, MCP
[](https://konghq.com/blog/engineering/mcp-servers-guide)
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
[](https://konghq.com/blog/engineering/api-ecosystems-for-the-agentic-era)
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
[](https://konghq.com/blog/product-releases/mcp-support-across-konnect)
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
[](https://konghq.com/blog/product-releases/api-productization-simplified-with-multiple-portals)
In the last blog post , we discussed the need for both speed and quality for your API delivery and how APIOps can help achieve both. In this part of our blog post series, we'll walk through what the API lifecycle looks like when following APIOps.
[](https://konghq.com/blog/enterprise/automating-api-lifecycle-apiops-part-2)