Manage Portal Members And Prospects

Overview

Handles the membership lifecycle of an API Experience Hub (AEH) portal. Prospects are users who have requested access but are not yet portal members; members are active users with assigned user groups. This workflow lets portal administrators approve or reject prospects, audit the member list, adjust user-group assignments per member, and disable members who should no longer have access.

What you'll build: A governed portal membership list with the right people assigned to the right user groups.

Prerequisites

Before starting, ensure:

  1. Authentication ready

    • Valid Bearer token for Anypoint Platform
    • AEH Administrator or AEH Portal Administrator permissions

  2. Environment already bootstrapped

    • Connection and portal exist (use the AEH UI if not)
    • At least one user group exists in the portal (see manage-portal-user-groups)

Step 1: List AEH Connections

Retrieve the AEH connections the user has access to.

api-experience-hub-management.getConnections 
$ curl -X GET ${baseUrl}/api/v1/connections \
  -H "Authorization: Bearer ${authToken}" \
  -H "Content-Type: application/json"
Captured Variables
connectionId $[*].id

What happens next: The chosen connectionId scopes every subsequent call.

Step 2: List Portals on the Connection

Pick the target portal whose membership you want to manage.

api-experience-hub-management.getAllApiPortalByConnectionId 
$ curl -X GET ${baseUrl}/api/v1/connections/{connectionId}/apiPortals \
  -H "Authorization: Bearer ${authToken}" \
  -H "Content-Type: application/json"
Captured Variables
portalId $[*].id

Step 3: List Pending Prospects

Retrieve the list of users who have requested access to the portal but are not yet members.

api-experience-hub-management.getProspects 
$ curl -X GET ${baseUrl}/api/v1/connections/{connectionId}/apiPortals/{portalId}/prospects \
  -H "Authorization: Bearer ${authToken}" \
  -H "Content-Type: application/json"
Captured Variables
prospects $.prospects[*]
prospectId $.prospects[*].id

What happens next: Present the prospect list and let the admin choose who to approve or reject.

Step 4: Approve a Prospect

Promote a prospect to an active portal member and assign them to one or more user groups. Repeat per prospect the admin wants to approve.

api-experience-hub-management.approveProspect 
$ curl -X PATCH ${baseUrl}/api/v1/connections/{connectionId}/apiPortals/{portalId}/prospects/{prospectId} \
  -H "Authorization: Bearer ${authToken}" \
  -H "Content-Type: application/json"
Captured Variables
approvedUserId $.userId

What happens next: The prospect is now a portal member with the chosen group assignments.

Step 5: Reject a Prospect (Optional)

Reject prospects who should not be granted access.

api-experience-hub-management.rejectProspect 
$ curl -X DELETE ${baseUrl}/api/v1/connections/{connectionId}/apiPortals/{portalId}/prospects/{prospectId} \
  -H "Authorization: Bearer ${authToken}" \
  -H "Content-Type: application/json"
Captured Variables
rejectedProspectId $.id

What happens next: The prospect is removed from the queue. They can re-request access later.

Step 6: List Portal Members

Retrieve active portal members to audit who currently has access.

api-experience-hub-management.getCommunityUsers 
$ curl -X GET ${baseUrl}/api/v1/connections/{connectionId}/apiPortals/{portalId}/users \
  -H "Authorization: Bearer ${authToken}" \
  -H "Content-Type: application/json"
Captured Variables
members $.users[*]
userId $.users[*].id

Step 7: Inspect a Member's User-Group Assignments

Fetch the specific group assignments of one member.

api-experience-hub-management.getCommunityUser 
$ curl -X GET ${baseUrl}/api/v1/connections/{connectionId}/apiPortals/{portalId}/users/{userId} \
  -H "Authorization: Bearer ${authToken}" \
  -H "Content-Type: application/json"
Captured Variables
memberUserGroups $.userGroups[*]

What happens next: Present the current assignments; let the admin decide new memberships for Step 8.

Step 8: Update a Member's User-Group Assignments

Replace or extend the user groups assigned to a specific member.

api-experience-hub-management.addGroupMappingToUser 
$ curl -X PUT ${baseUrl}/api/v1/connections/{connectionId}/apiPortals/{portalId}/users/{targetUserId}/userGroups \
  -H "Authorization: Bearer ${authToken}" \
  -H "Content-Type: application/json"
Captured Variables
updatedUserId $.userId

What happens next: The member now has exactly the user groups you specified.

Step 9: Disable a Portal Member (Optional)

Revoke a member's access without deleting their record — useful for offboarding.

api-experience-hub-management.disableCommunityUser 
$ curl -X PATCH ${baseUrl}/api/v1/connections/{connectionId}/apiPortals/{portalId}/users/{targetUserId}/disable \
  -H "Authorization: Bearer ${authToken}" \
  -H "Content-Type: application/json"
Captured Variables
disabledUserId $.userId

What happens next: The disabled member can no longer sign in to the portal. Their API contracts remain intact for audit.

Completion Checklist

  • [ ] Connection and portal selected
  • [ ] Pending prospects reviewed
  • [ ] Approved prospects assigned to correct user groups
  • [ ] Unwanted prospects rejected
  • [ ] Existing members' group assignments audited
  • [ ] Offboarded members disabled (if applicable)

What You've Built

✅ Governed Portal Membership — Prospects are triaged and approved members have the right user-group entitlements.

Next Steps

  1. Manage user groups themselves — See manage-portal-user-groups to define the groups referenced here.
  2. Curate the visible catalog — See curate-portal-assets to control which APIs members see.
  3. Monitor contracts — Track which approved members create consumer contracts against published APIs.