Skip to main content

Introduction

API Access Requests are formal requests from API Consumers to access specific API Products and Plans through the Developer Portal. These requests initiate the workflow for granting, or provisioning, API access to users.

Understanding the Provisioning Request Workflow

When API Consumers discover APIs in your Catalog that they need access to, they initiate a API Access Request through the Live Portal. This request:
  • Identifies the specific API Product and subscriptionPlan they want to access
  • Specifies which Developer App should receive the access credentials
  • Creates an auditable record of the access request
Depending on your configuration, these requests can be processed automatically or require manual approval.

Requesting Access to an API Product

API Consumers can request access to API Products through the Live Portal using one of two configured flows. To learn how to configure this flow visit Access Flow Types

Initial Steps (Both Flows):

  1. From the Catalogues page, choose the API Product of interest and select More info
  2. On the API Product detail page, decide which of the available Plans to subscribe to and select Access with this Plan
  3. The next steps depend on your portal’s configured access flow:

Direct Access Flow

When Direct Access Flow is enabled, you can request access to API Products immediately without using a shopping cart. Steps:
  • You’ll be taken directly to the access request page with your selected product and plan pre-populated
  • Select or create a Developer App to store your credentials
  • Configure credentials (new or extend existing compatible credentials)
  • Select Continue to submit your request
Credential Compatibility Rules For existing credentials to be compatible, they must:
  • Have the same Plan as the selected product
  • Not already include the selected product
  • Have a matching authentication type with the product
For more information, refer to this guide

Cart-Based Flow

When Cart-Based Flow is enabled, you can add multiple API Products to a shopping cart before submitting a single access request. Steps:
  • The API Product and Plan combination will be added to your cart
  • Repeat steps 1-2 for additional API Products you want to access
  • Go to the Cart using the icon in the top right of the screen
  • Review your selections and select a Developer App
  • Select Submit request

After Submission

  • Your access request will be submitted for approval (if required)
  • Track request status in My Apps
  • Once approved, credentials will be available in your selected Developer App

Manual Approval Workflow

The manual approval workflow provides API Owners with oversight of all API access. When an API Consumer completes an access request, API Owners receive notification of pending request via email and should then:
  1. Navigate to the API Consumers > Access Requests page in the Admin Portal
  2. Review the request
    • User name
    • Developer App
    • Requested API Products
    • Selected subscription Plan
  3. Approve or reject the request from the three dot menu
    • If approved, access is provisioned with credentials issued to the specified Developer App
    • If rejected, access will not be granted
    • API Consumer receives notification of the decision via email

Automatic Approval Workflow

For trusted users or specific API Products, you can enable automatic approval in the subscription Plan. To configure automatic approval, the API Owner should:
  1. Navigate to the Plans page in the Admin Portal
  2. Select or create the API Plan that should be automatically approved
  3. Set the Auto approve access request checkbox Auto Approve API provisioning requests
  4. Select Save changes
When an API Consumer requests access using this plan, the request will be approved immediately and access credentials provisioned to the Developer App.
Despite automatic approval, a record of the request is maintained in the API Consumers > Access requests page in the Admin Portal.

Notification of Decision

The Dev Portal sends notification to the API Consumer when their request is approved or rejected. If the email service is configured, then:
  • When a request is approved:
    • The system sends an approval notification email to the user
    • The email uses the template “approve” with a configurable subject
    • The notification includes details about the approved access
  • When a request is rejected:
    • The system sends a rejection notification email to the user
    • The email uses the template “reject” with a configurable subject

Update Products and Plans of an Access Request

Starting from v1.16.0, the Tyk Developer Portal enables users to efficiently manage their access requests by adding or removing API Products and modifying subscription plans for existing credentials. This eliminates credential sprawl and provides a streamlined experience. The following features can be accessed via “App” page, under each access credential.

Adding Products to Existing Access Request

Users can extend their existing credentials with additional API Products when compatibility requirements are met, avoiding the need to creating new credentials for additional API products. Compatibility Requirements Products can be added to existing credentials when they share:
  • Same authentication method
  • Same subscription plan
  • Products not already included in the credential
When requesting access to an API Product, developers can choose to create a new credential or use one of the compatible existing credential. For more information, refer to this guide

Removing Products from Access Requests

Users can remove individual API Products from credentials that contain multiple products, maintaining access to remaining products while revoking access to unwanted ones. This provides granular control over application permissions without affecting the entire credential.

Plan Management

Users can update subscription plans for existing access requests without generating new credentials. Plan modifications maintain existing product associations where compatibility allows.