API catalog vs. API developer portal: main differences

May 30, 2024

API catalog vs. API developer portal: main differences

Ready to start?

There’s an API explosion going on.

The move to cloud-native development, breaking up of silos into microservices, adoption of API-first and API-enabled approaches, all led to great innovation. These changes also brought a lot of complexity and made the developer experience more difficult and fragmented. Managers and leaders also have related questions around API governance, quality and control.

APIs are created often without a centralized place for management and governance. This explosion of APIs led to a chaotic landscape where the following becomes a challenge:

  • Discoverability: Letting developers find the right API for a specific task or project.
  • Documentation: Helping developers access up-to-date API documentation.
  • Governance: Providing the assurance to engineering leadership that APIs are compliant, consistent, of good quality and secure. .
  • Optimization: Ensuring the engineering organization as a whole avoids effort duplication. 

The latter point is important. With API explosion and no way to manage them, valuable engineering resources are hidden, underutilized, or even duplicated. This not only harms productivity and slows down development velocity but also creates security and governance risks.

Without a central, globally searchable source of truth for API existence or quality, the easiest path is to create an overlapping API or (less commonly) completely duplicate an API, thus hindering current and planned modernization.

To solve this issue, organizations are turning to two essential tools: API catalogs and internal developer portals with an API catalog. But what exactly are they, and how are they different? In this blog post, we'll discuss API catalogs and API portals, exploring how they can help you regain control of your API ecosystem.

Internal vs. External API Catalogs

It's important to note that API catalogs can serve two different purposes for two different audiences. 

  • Internal API Catalogs, which are designed for use within an organization, primarily serving developers or other internal stakeholders. They focus on promoting code reuse, and efficient development by providing a centralized repository of internal APIs with their documentation.
  • External API Catalogs: These serve customers, partners, and others, interested in integrating with a company's products or services. 

In this article, we will focus on internal API catalogs (also referred to here as API catalogs). 

What are API catalogs? 

An API catalog is a central repository for all APIs within an organization, where developers and other stakeholders such as product managers can easily discover, access, and understand all APIs available without the need to reach out to contacts or search through various systems.

Traditionally, API catalogs include the following information:

  • Functionality: a description of what the API does.
  • Code snippets: request and response examples
  • Parameters: the input values required to trigger specific functionalities.
  • Error codes: a list of the potential errors that the API might return
  • Authentication mechanisms: the methods used by the API to check the identity of the applications trying to access it. 

Such API catalogs can appear as a feature in tools like postman, or Smartbear which allows developers to test, document, and share APIs, by providing a user-friendly interface for making requests, viewing responses, and debugging issues.
However, advanced API catalogs go beyond the basics and offer a more comprehensive experience. They’ll usually include additional information that is valuable for both API owners and consumers:

  • Usage statistics that includes information such as when the API was last called, which services are using it most frequently, and the average response time.
  • Developer feedback, allowing developers to rate and review APIs.
  • Health score, that indicates the overall performance and reliability of an API
  • Additional metadata: You can add to the catalog additional information such as API ownership, contact details for support, and links to other relevant resources. 

Why should you use an API catalog? 

By providing this additional information, the API catalog allows developers looking to use an API to:

  • Make informed decisions: Select the right APIs for their projects based on usage data and feedback.
  • Collaborate effectively: Share feedback and ratings to help improve the API ecosystem.

For API owners, the benefits are:

  • Understand API usage: Get insights into how APIs are being used, shedding light into popular endpoints, usage patterns, and potential bottlenecks.
  • Troubleshoot issues: Identify potential problems with an API based on its health score and usage patterns.
  • Improve communication: Address concerns, announce updates, and gather input.

API catalog tools can be found as a feature in popular API management platforms, such as Postman and Apigee. Additionally, you can build an open source API catalog with tyk.io and other similar tools. 

What is an API catalog in an internal developer portal?

Internal developer portals were built to solve similar problems to those addressed by API catalogs. Instead of solving issues of API explosion, they address the issues of microservices explosion. However, their inherent capabilities allow the inclusion of API data into the software catalog at the heart of the portal, supporting an API catalog use case for the portal.

Internal developers were built to solve a larger problem of developer experience and developer self-service and are made to provide strong context and data to developers, abstracted for them, alongside developer self service actions. As such, they offer more than traditional API catalogs by showing 

  • APIs in context
  • Enriched metadata or structured performance feedback on the quality of the API

They also deliver improved developer experiences across self-service, workflow automations and the ability to better control quality and compliance of APIs, using scorecards.

Self-service actions 

A key differentiator of API developer portals is their self-service capabilities. They allow developers to:

  • Easily scaffold APIs that are compliant and secure by default: By creating templates and exposing them to developers, you can ensure that new APIs comply with organizational standards and promote consistency and reliability. 
  • Streamline API Lifecycle Management: Create self-service actions to register, publish, certify, deploy, and deprecate your APIs, all from one unified interface. 

Scorecards

Scorecards help ensure API quality and compliance. They evaluate the API against predefined rules and provide important insights to API owners, consumers as well as for  engineering management. Scorecards can be used for 

  • Security: Scorecards can check for example HTTPS enforcement, authentication mechanisms, and other security best practices.
  • Reliability: Monitor API response times, error rates, and other performance indicators.
  • Production Readiness: Assess if an API has an owner, proper documentation, configured health checks, and other essential elements.

Initiatives

API developer portals enable managers to track and manage initiatives aimed at improving API governance. Using initiatives, you can easily:

  • Identify APIs that lack proper documentation or don’t meet mandatory requirements.
  • Monitor how many APIs still need attention.

Dashboards

Dashboards provide customized information to different stakeholders, easing API governance and troubleshooting. Using a developer portal you can create the following dashboards

  • A manager dashboard: Focus on business-critical APIs, displaying the most used APIs, their response times, distribution of response codes, and progress on key initiatives.
  • An API owner dashboard: Offer insights into individual API performance, including monitoring data, recent feedback, health scores, and top consumers. 

Main differences between API catalogs and API developer portals

API catalogs act as a central repository for APIs. They offer a searchable index as well as detailed documentation for each API. This documentation typically covers functionalities, endpoints, parameters, request and response formats, error codes, and usage examples. Essentially, API catalogs help developers discover relevant APIs and understand how to use them best.

API developer portals, however, go beyond just discovery and documentation. They provide a platform that lets developers manage the entire API lifecycle. This includes tasks like creating new APIs using templates, registering API, publishing them, and eventually deprecating them when they are no longer needed. Additionally, developer portals often integrate with API management tools, enabling functionalities like API security enforcement, rate limiting, and analytics.

In short, while API catalogs are often a core component of a developer portal, it represents just one piece of the puzzle.

Beyond APIs - all developer experiences in one place 

While APIs are critical assets in every engineering organization, they are not the only software components that developers need to manage throughout the SDLC. Developers also work with services, packages, deployments, and more.

A developer portal recognizes this interconnectedness and provides a unified platform where developers can manage all these components seamlessly. 

By integrating API management into the broader development workflow, organizations can achieve:

  • A streamlined end to end development experience: Developers can manage all aspects of their projects—from code repositories and build pipelines to API documentation and deployment configurations—within a single centralized place.This eliminates the need to switch between multiple siloed tools and reduces cognitive load.
  • Better Collaboration: Using a portal, developers can share information about APIs, services, and deployments and more, easing communication and knowledge sharing.
  • Improved Visibility: Teams can track the progress of projects, identify dependencies, and assess the impact of changes across different components.

By including more than just API management, developer portals become the place for everything development, allowing teams to work more effectively, deliver higher quality software, and accelerate innovation.

Conclusion

Using an internal developer portal, platform engineers can create a single, searchable API marketplace that will reduce waste and cognitive load and offer developers

  • The confidence in the quality of the APIs consumed 
  • APIs that are held to a high standard 
  • The ability to scaffold new APIs
  • In context data about APIs, which services consume them etc
{{cta_1}}

Check out Port's pre-populated demo and see what it's all about.

Check live demo

No email required

{{cta_2}}

Contact sales for a technical product walkthrough

Let’s start
{{cta_3}}

Open a free Port account. No credit card required

Let’s start
{{cta_4}}

Watch Port live coding videos - setting up an internal developer portal & platform

Let’s start
{{cta_5}}

Check out Port's pre-populated demo and see what it's all about.

(no email required)

Let’s start
{{cta_6}}

Contact sales for a technical product walkthrough

Let’s start
{{cta_7}}

Open a free Port account. No credit card required

Let’s start
{{cta_8}}

Watch Port live coding videos - setting up an internal developer portal & platform

Let’s start
{{cta-demo}}
{{reading-box-backstage-vs-port}}

Example JSON block

{
  "foo": "bar"
}

Order Domain

{
  "properties": {},
  "relations": {},
  "title": "Orders",
  "identifier": "Orders"
}

Cart System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Cart",
  "title": "Cart"
}

Products System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Products",
  "title": "Products"
}

Cart Resource

{
  "properties": {
    "type": "postgress"
  },
  "relations": {},
  "icon": "GPU",
  "title": "Cart SQL database",
  "identifier": "cart-sql-sb"
}

Cart API

{
 "identifier": "CartAPI",
 "title": "Cart API",
 "blueprint": "API",
 "properties": {
   "type": "Open API"
 },
 "relations": {
   "provider": "CartService"
 },
 "icon": "Link"
}

Core Kafka Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Kafka Library",
  "identifier": "CoreKafkaLibrary"
}

Core Payment Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Payment Library",
  "identifier": "CorePaymentLibrary"
}

Cart Service JSON

{
 "identifier": "CartService",
 "title": "Cart Service",
 "blueprint": "Component",
 "properties": {
   "type": "service"
 },
 "relations": {
   "system": "Cart",
   "resources": [
     "cart-sql-sb"
   ],
   "consumesApi": [],
   "components": [
     "CorePaymentLibrary",
     "CoreKafkaLibrary"
   ]
 },
 "icon": "Cloud"
}

Products Service JSON

{
  "identifier": "ProductsService",
  "title": "Products Service",
  "blueprint": "Component",
  "properties": {
    "type": "service"
  },
  "relations": {
    "system": "Products",
    "consumesApi": [
      "CartAPI"
    ],
    "components": []
  }
}

Component Blueprint

{
 "identifier": "Component",
 "title": "Component",
 "icon": "Cloud",
 "schema": {
   "properties": {
     "type": {
       "enum": [
         "service",
         "library"
       ],
       "icon": "Docs",
       "type": "string",
       "enumColors": {
         "service": "blue",
         "library": "green"
       }
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "system": {
     "target": "System",
     "required": false,
     "many": false
   },
   "resources": {
     "target": "Resource",
     "required": false,
     "many": true
   },
   "consumesApi": {
     "target": "API",
     "required": false,
     "many": true
   },
   "components": {
     "target": "Component",
     "required": false,
     "many": true
   },
   "providesApi": {
     "target": "API",
     "required": false,
     "many": false
   }
 }
}

Resource Blueprint

{
 “identifier”: “Resource”,
 “title”: “Resource”,
 “icon”: “DevopsTool”,
 “schema”: {
   “properties”: {
     “type”: {
       “enum”: [
         “postgress”,
         “kafka-topic”,
         “rabbit-queue”,
         “s3-bucket”
       ],
       “icon”: “Docs”,
       “type”: “string”
     }
   },
   “required”: []
 },
 “mirrorProperties”: {},
 “formulaProperties”: {},
 “calculationProperties”: {},
 “relations”: {}
}

API Blueprint

{
 "identifier": "API",
 "title": "API",
 "icon": "Link",
 "schema": {
   "properties": {
     "type": {
       "type": "string",
       "enum": [
         "Open API",
         "grpc"
       ]
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "provider": {
     "target": "Component",
     "required": true,
     "many": false
   }
 }
}

Domain Blueprint

{
 "identifier": "Domain",
 "title": "Domain",
 "icon": "Server",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {}
}

System Blueprint

{
 "identifier": "System",
 "title": "System",
 "icon": "DevopsTool",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "domain": {
     "target": "Domain",
     "required": true,
     "many": false
   }
 }
}
{{tabel-1}}

Microservices SDLC

  • Scaffold a new microservice

  • Deploy (canary or blue-green)

  • Feature flagging

  • Revert

  • Lock deployments

  • Add Secret

  • Force merge pull request (skip tests on crises)

  • Add environment variable to service

  • Add IaC to the service

  • Upgrade package version

Development environments

  • Spin up a developer environment for 5 days

  • ETL mock data to environment

  • Invite developer to the environment

  • Extend TTL by 3 days

Cloud resources

  • Provision a cloud resource

  • Modify a cloud resource

  • Get permissions to access cloud resource

SRE actions

  • Update pod count

  • Update auto-scaling group

  • Execute incident response runbook automation

Data Engineering

  • Add / Remove / Update Column to table

  • Run Airflow DAG

  • Duplicate table

Backoffice

  • Change customer configuration

  • Update customer software version

  • Upgrade - Downgrade plan tier

  • Create - Delete customer

Machine learning actions

  • Train model

  • Pre-process dataset

  • Deploy

  • A/B testing traffic route

  • Revert

  • Spin up remote Jupyter notebook

{{tabel-2}}

Engineering tools

  • Observability

  • Tasks management

  • CI/CD

  • On-Call management

  • Troubleshooting tools

  • DevSecOps

  • Runbooks

Infrastructure

  • Cloud Resources

  • K8S

  • Containers & Serverless

  • IaC

  • Databases

  • Environments

  • Regions

Software and more

  • Microservices

  • Docker Images

  • Docs

  • APIs

  • 3rd parties

  • Runbooks

  • Cron jobs

Starting with Port is simple, fast and free.

Let’s start