Comprehensive Indexing of Collective Web Services: An Introduction to public-apis
The public-apis repository hosted on GitHub represents one of the largest, most active, and most highly regarded open-source directories of free Application Programming Interfaces (APIs) available to developers, data scientists, researchers, and software engineers worldwide. Maintained as an open community-driven catalog, the project aggregates, organizes, and continuously indexes hundreds of public web endpoints across dozens of distinct domain categories. These categories span a vast spectrum of digital utility, ranging from real-time financial market feeds and machine learning endpoints to complex geocoding engines, weather telemetry systems, continuous integration utilities, and developer tooling.
Modern software development relies heavily on third-party API integration. Whether software engineers are engineering rapid prototypes during hackathons, assembling enterprise-grade microservice architectures, building cross-platform mobile applications, or delivering hands-on computer science curricula, they frequently require immediate access to structured external data feeds and remote execution engines. The public-apis repository directly addresses this operational necessity by delivering a centralized, standardized, and machine-readable directory of public endpoints that offer free usage tiers or unrestricted open access without the friction of commercial payment barriers.
Far beyond functioning as a static bookmark collection, the public-apis project enforces rigorous organizational standards, standardized metadata schemas, automated validation pipelines, and precise categorical taxonomies. Every single entry cataloged within the directory outlines critical technical characteristics—including authentication requirements, transport layer security (HTTPS) support, and Cross-Origin Resource Sharing (CORS) policy configurations. This structured metadata allows system architects and software developers to evaluate endpoint compatibility with their specific client or server application architecture prior to writing integration code.
In an ecosystem dominated by commercial API gateways, complex vendor onboarding flows, and monetized developer portals, the public-apis repository serves as a critical open-access index. By maintaining a clean, community-curated index on GitHub, the project lowers the barrier to entry for developers worldwide, facilitating software experimentation, education, and rapid proof-of-concept development across diverse technology stacks.
What the Project Is and Why It Matters
At its core, the public-apis repository is a meticulously curated, community-managed directory stored primarily in structured Markdown format within a central GitHub repository. The underlying objective of the project is to discover, aggregate, categorize, and validate free web services that provide practical utility for software development across all skill levels. The repository operates under an open governance model, relying on a global network of open-source contributors to submit newly discovered public endpoints, prune non-functional or deprecated links, rectify inaccurate metadata, and refine categorical structures.
Locating functional, reliable, and genuinely free APIs across the broader web can be a fragmented, inefficient, and time-consuming task. Commercial API marketplaces routinely prioritize monetized services, mandate complex vendor onboarding processes, or obscure restrictive rate limits and hidden paywalls. Conversely, uncurated forum threads, informal lists, and personal blog posts frequently suffer from bit rot—containing abandoned endpoints, dead links, inaccurate path descriptions, or missing access requirements. The public-apis project systematically resolves these operational pain points through four foundational design principles:
- Centralized Indexing: Eliminates the necessity for manual, unguided web searches across disparate service provider portals by consolidating public endpoints into a single, comprehensive reference document.
- Provides a single source of truth for free web services.
- Categorizes endpoints by technical domain for rapid technical evaluation.
- Metadata Transparency: Exposes vital execution attributes—such as required authentication protocols, SSL/TLS encryption support, and CORS header support—directly within the top-level index table for immediate inspection.
- Reduces discovery time by highlighting protocol constraints upfront.
- Enables developers to quickly screen out incompatible endpoints for browser-based applications.
- Automated Quality Assurance: Employs continuous integration (CI) test workflows and automated Python validation scripts to strictly enforce alphabetical sorting rules, formatting compliance, link validity, and endpoint availability.
- Prevents broken syntax and invalid entries from reaching the main branch.
- Ensures consistent table structures across all domain categories.
- Open Community Governance: Empowers any software engineer or community contributor to submit newly discovered endpoints, update existing listings, or optimize taxonomy structures using standard Git pull request pipelines.
- Fosters continuous updates driven by global community usage.
- Leverages collective oversight to identify deprecated endpoints quickly.
Through these foundational principles, the public-apis repository functions not only as a catalog, but as a reliable infrastructure layer for software engineers planning new projects, evaluating backend integration dependencies, or searching for public data sources.
Metadata Architecture and Standardized Entry Format
To ensure uniform structure across hundreds of indexed web services, the public-apis repository enforces a strict, standardized metadata schema for every cataloged API. Each service is documented as an individual row within a Markdown table positioned under its corresponding primary category heading. The metadata schema mandates six primary parameters:
| Field | Type | Technical Description | Architectural Significance |
|---|---|---|---|
| API | String / Hyperlink | The formal title or brand name of the API, formatted as an HTML/Markdown hyperlink pointing directly to its official developer documentation or landing page. | Provides immediate access to official integration documentation, endpoint path definitions, payload structures, and terms of service. |
| Description | String | A concise, single-sentence summary detailing the primary operational scope, business domain, or data payloads offered by the service. | Allows developers to rapidly scan list entries and assess functional fit without leaving the directory index. |
| Auth | Enum String | Defines the credential requirement necessary to issue valid requests (e.g., No, apiKey, OAuth, or User-Agent). |
Determines client credential management requirements, secret storage needs, and authorization workflow complexity. |
| HTTPS | Boolean String | Specifies whether the endpoint supports or enforces encrypted HTTP communications via TLS/SSL (Yes or No). |
Informs network security posture and ensures compliance with modern browser mixed-content security policies. |
| CORS | Enum String | Indicates whether Cross-Origin Resource Sharing is permitted for browser-based HTTP requests (Yes, No, or Unknown). |
Dictates whether browser client applications can fetch data directly or require an intermediate backend proxy server. |
| Link | URL String | The target URL destination embedded within the API title column, used both for user navigation and automated link checking. | Serves as the canonical endpoint location target evaluated by continuous integration link-checking routines. |
Thorough evaluation of these metadata fields is essential when selecting an API for a given system architecture. For example, browser-side single-page applications (SPAs) built with modern JavaScript frameworks like React, Vue, or Angular require endpoints that explicitly offer full CORS support (CORS: Yes) and enforce secure transport (HTTPS: Yes). In contrast, server-side applications running in environments like Node.js, Python, Go, or Java operate outside browser sandbox constraints, bypassing CORS limitations entirely and expanding the pool of compatible services.
By standardizing these metadata parameters across all indexed items, the repository converts thousands of disparate web pages into a clean, queryable technical taxonomy that can be parsed manually or processed programmatically via custom scripts.
Detailed Categorization Taxonomy
The public-apis repository organizes its expansive collection of public web services into a clean, topically aligned taxonomy. This categorical organization enables rapid discovery of domain-specific data sources and compute endpoints. Below is a detailed technical overview of the primary categories managed within the index, along with representative service examples:
1. Development and Infrastructure Tools
This category aggregates endpoints explicitly designed to assist software engineers, platform engineering teams, build systems, continuous integration pipelines, and data verification routines. Essential sub-domains include:
- Development Utilities: Remote code execution sandboxes, code snippet storage engines, programming language execution utilities, and repository analytics feeds.
- JSONPlaceholder: Free fake REST API for testing and prototyping.
- httpbin: HTTP Request & Response Service for testing headers and methods.
- Data Validation: Automated email deliverability checkers, international phone number format validators, IP address intelligence lookup feeds, and JSON/XML schema syntax checkers.
- Continuous Integration & Badging: Automated build status badging services, deployment pipeline triggers, automated testing reporting endpoints, and continuous delivery metrics tools.
2. Financial Services and Economics
Financial APIs deliver quantitative data essential for fintech systems, algorithmic trading routines, accounting software, and economic research dashboards:
- Cryptocurrency: Real-time exchange rates, public blockchain ledger inspection, cryptographic wallet balance queries, ticker metrics, and token contract metadata.
- CoinGecko API: Comprehensive crypto market data including prices, volume, and market capitalization.
- Blockchain.info API: Public blockchain data and transaction queries.
- Currency Exchange: Foreign exchange (Forex) spot rates, central bank reference conversion factors, fiat currency converters, and historical exchange rate tables.
- Finance & Economy: Equity market price feeds, commodities metrics, macroeconomic indicators, inflation tracking data, and official corporate financial filings.
3. Geospatial, Environment, and Logistics
Geospatial and environmental services supply location-aware platforms with mapping, routing, environmental tracking, and asset monitoring capabilities:
- Geocoding & Location: Forward and reverse geocoding engines, address parsing utilities, IP-to-geolocation mapping, and administrative territorial boundaries.
- ipapi: Real-time IP address location lookup and network details.
- OpenStreetMap Nominatim: Search OSM data by name and address (reverse geocoding).
- Transportation & Logistics: Global flight position tracking, municipal public transit schedules, ocean vessel AIS tracking, traffic congestion data, and postal carrier tracking updates.
- Environment & Weather: Atmospheric telemetry, weather forecasts, air quality indices, global seismic activity streams, and oceanographic research feeds.
- Open-Meteo: Open-source weather API offering forecast data without requiring an API key.
- USGS Earthquake Hazards Program: Real-time global seismic updates and historical earthquake data.
4. Machine Learning, Science, and Education
APIs listed in these categories provide specialized computational models, natural language processing, scientific datasets, and academic infrastructure:
- Machine Learning & Text Analysis: Natural language generation, sentiment classification, machine translation layers, named entity recognition (NER), and image recognition models.
- Science & Math: Astronomical event data from agencies like NASA, automated mathematical equation solvers, particle physics tracking data, and chemical database queries.
- NASA Open APIs: APOD (Astronomy Picture of the Day), Mars Rover Photos, and Near-Earth Object Web Service.
- Universities & Open Data: Academic institution indices, municipal civic data archives, government open-data portals, and public library catalog endpoints.
- REST Countries: Detailed statistics on world nations including currencies, capital cities, and flags.
5. Media, Entertainment, and Social Systems
Rich digital applications rely on media and social APIs to stream creative assets, dynamic content, user communications, and community platform metrics:
- Art, Design, & Photography: Royalty-free stock photography feeds, dynamic color palette generators, vector icon catalog queries, museum digital archives, and font metadata.
- Unsplash API: Access to high-resolution photography libraries.
- Metropolitan Museum of Art API: Open access to data for over 470,000 collection objects.
- Games, Anime, & Entertainment: Video game metadata databases, collectible card game state engine queries, pop-culture trivia APIs, and streaming content availability feeds.
- PokéAPI: Complete RESTful interface for Pokémon statistics, moves, and abilities.
- Social & Communications: Chat bot integration gateways, SMS and messaging transmission interfaces, RSS-to-JSON parsers, and social platform engagement statistics.
Authentication Protocols and Security Architecture
Public web APIs cataloged across the directory employ various access control standards. Understanding these authentication models is crucial for properly engineering client requests, storing credentials safely, and avoiding service interruptions.
No Authentication (Auth: No)
Services classified with Auth: No do not require API keys, secret tokens, or user registration. Clients can execute requests immediately using standard HTTP verbs (such as GET or POST). These endpoints are exceptionally valuable for rapid prototyping, sandbox testing, educational workshops, and client-side web demos where managing secret keys is unfeasible or unnecessary.
An example of issuing an unauthenticated HTTP GET request in JavaScript using the native Fetch API:
// Fetching public exchange rates without authentication
fetch("https://open.er-api.com/v6/latest/USD")
.then(response => {
if (!response.ok) {
throw new Error(`HTTP error! Status: ${response.status}`);
}
return response.json();
})
.then(data => console.log("Exchange Rates:", data))
.catch(error => console.error("Fetch Error:", error));
API Key Authentication (Auth: apiKey)
APIs specifying Auth: apiKey require requesting clients to transmit a unique identification string alongside every HTTP request. Service providers utilize API keys to identify the requesting application, track consumption, enforce rate limits, and block malicious traffic. API keys are generally passed via one of three HTTP transport structures:
- HTTP Header Field: Embedded within custom authorization headers (e.g.,
X-API-Key: custom_secret_value) or standardizedAuthorizationheader fields. - URL Query Parameter: Appended directly to the URI string (e.g.,
https://api.example.com/v1/data?apikey=custom_secret_value). - Request Body Payload: Included as a key-value pair within serialized JSON or form-encoded POST payloads.
When interacting with API key endpoints from browser environments, developers must recognize that keys embedded in client-side JavaScript code or exposed in query parameters are visible to end users via browser developer tools. To prevent unauthorized key theft and usage quota depletion, developers should route client traffic through serverless functions or backend API proxies where credentials remain safely stored in environment variables.
OAuth Protocols (Auth: OAuth)
Endpoints listed with Auth: OAuth mandate standard token-based authorization frameworks, primarily OAuth 2.0. These workflows require client applications to complete an authorization grant flow to obtain short-lived access tokens (and optional refresh tokens) prior to requesting protected resources. OAuth authentication is typically enforced by services that manage user-specific private data, provide write access to resources, or enforce multi-tenant enterprise access controls.
User-Agent Requirements (Auth: User-Agent)
Certain public services enforce strict HTTP User-Agent header inspection to identify incoming client software and block unidentifiable automated web scrapers or misconfigured bots. Requests submitted without a properly populated, descriptive User-Agent string may be rejected immediately with HTTP error status codes such as 403 Forbidden or 429 Too Many Requests.
An example of setting a custom User-Agent header in a Python request:
import requests
url = "https://api.github.com/zen"
headers = {
"User-Agent": "MyCustomApplication/1.0 (contact@example.com)"
}
response = requests.get(url, headers=headers)
if response.status_code == 200:
print("GitHub Zen:", response.text)
else:
print(f"Request failed with status code {response.status_code}")Understanding Cross-Origin Resource Sharing (CORS) and HTTPS Security
Modern browser security models enforce stringent rules regarding how web applications handle HTTP requests made across different origin domains. The public-apis directory provides explicit metadata tracking for both HTTPS availability and CORS header support to eliminate integration issues early in the design phase.
The Technical Role of HTTPS Encryption
The HTTPS column inside the directory explicitly confirms whether an API serves traffic using HTTP Secure over Transport Layer Security (TLS/SSL). In modern web engineering, HTTPS support is non-negotiable due to several technical security enforcement mechanisms:
- Mixed Content Restrictions: Modern web browsers strictly prohibit unencrypted HTTP requests initiated from web applications served over secure HTTPS origins, triggering instant Mixed Content blocking.
- Payload Integrity and Confidentiality: Encrypts transit payloads moving between the client application and the API host, preventing packet sniffing, credential theft, and man-in-the-middle (MitM) data modification.
- Credential Safeguarding: Guarantees that sensitive authentication headers, API keys, and bearer tokens are fully encrypted prior to transmission across public network infrastructure.
Cross-Origin Resource Sharing (CORS) Mechanics
CORS is a browser-enforced security mechanism designed to guard against unauthorized cross-domain data access under the Same-Origin Policy (SOP). When a client application running at https://app.example.com issues an asynchronous HTTP request (via standard fetch() or axios) to an external API at https://api.external-service.com, the browser attaches an HTTP Origin header to the request.
The destination server must evaluate the incoming origin and return specific CORS response headers—most notably Access-Control-Allow-Origin: * or Access-Control-Allow-Origin: https://app.example.com. If these headers are missing or restrict cross-origin access, the browser blocks the response payload from being read by client-side JavaScript code.
Within the public-apis repository, CORS statuses are classified as follows:
CORS: Yes: The server delivers permissive CORS response headers, enabling direct browser-to-API asynchronous requests from any web origin.CORS: No: The server does not provide CORS headers. Direct browser requests will fail due to Same-Origin Policy enforcement, requiring calls to be routed through a server-side proxy.CORS: Unknown: CORS policy implementation is variable, dependent on specific sub-routes, or unverified by continuous integration testing.
Automated Validation Workflow and Repository Maintenance
Maintaining an open-source index containing hundreds of dynamic external web links demands continuous automated validation and strict repository contribution rules. The public-apis project maintains database accuracy and syntax integrity using dedicated Python automation scripts and GitHub Actions continuous integration workflows.
Automated Validation Scripts
The repository features an automated testing script located at scripts/validate.py. This script is triggered automatically on every pull request and can also be executed locally by contributors. The script evaluates the Markdown source code against strict validation requirements:
- Alphabetical Order Enforcement: Category headings, table headers, and individual API rows inside every table must strictly follow alphabetical ordering by title.
- Markdown Table Syntax Checks: Ensures that all Markdown tables maintain correct pipe delimiter alignment, valid column counts, and consistent header separator rows.
- Duplicate Link Detection: Scans the target links across the entire repository to prevent duplicate URL submissions or redundant entries across categories.
- Protocol and Link Integrity: Verifies that target links use valid URI formatting and adhere to declared HTTPS protocols.
- Metadata Enumeration Normalization: Confirms that fields for
Auth,HTTPS, andCORScontain valid enumeration strings (e.g., rejecting invalid inputs likeTrue,False, or unapproved authentication tags).
Executing Local Validation Testing
Before submitting a pull request to the public-apis repository, contributors can execute the Python validation script locally within their development environment to catch syntax or ordering errors early:
# Step 1: Clone the public-apis repository from GitHub
git clone https://github.com/public-apis/public-apis.git
# Step 2: Navigate into the root project directory
cd public-apis
# Step 3: Run the automated Python validation script
python scripts/validate.py
If the validation script encounters alphabetical sorting errors, broken pipe formatting, or invalid enum values, it outputs precise line numbers and technical failure descriptions to standard output, allowing contributors to correct issues prior to requesting maintainer review.
Step-by-Step Contribution Guidelines
The public-apis project thrives on community contributions. To maintain high data quality across the catalog, prospective contributors must adhere to a standardized submission workflow when proposing new API listings or updating existing records.
Step 1: Verify Endpoint Qualification Criteria
Prior to editing the catalog, contributors must ensure the proposed API meets all foundational eligibility requirements:
- Genuinely Free Tier: The service must provide a permanently free operational tier or unrestricted open public access without requiring upfront credit card details.
- Operational Uptime and Stability: The target service must be fully operational, demonstrate reliable uptime, and provide publicly accessible developer documentation.
- Catalog Uniqueness: The API must not already exist within the repository dataset under a different category or alternative title.
Step 2: Format the Entry in Markdown
Locate the primary category section inside the main README.md file that matches the target endpoint domain. Insert a new Markdown table row in strict alphabetical order relative to existing entries. A valid Markdown entry row must follow this standard format:
| API | Description | Auth | HTTPS | CORS | Link |
| :--- | :--- | :--- | :--- | :--- | :--- |
| [Example API](https://api.example.com/docs) | Delivers real-time environmental metrics and air quality telemetry | `apiKey` | Yes | Yes | `https://api.example.com/docs` |
Step 3: Run Validation and Open a Pull Request
Run python scripts/validate.py locally to verify that alphabetical order, table structure, and link formats are valid. Once tests pass, commit the modifications using clear, descriptive Git commit messages, push the branch to your personal repository fork, and open a formal Pull Request against the primary branch of public-apis/public-apis.
Practical Integration Scenarios and Application Paradigms
The cataloged APIs within the public-apis directory support a wide array of application architectures and engineering requirements.
1. Rapid Prototyping and Hackathons
In time-constrained hackathons or rapid prototyping sprints, developers need immediate access to external data feeds without spending time setting up databases, navigating complex registration gateways, or managing complex authorization flows. By filtering the catalog for entries with Auth: No and CORS: Yes, developers can rapidly fetch live dynamic data directly into frontend web applications within minutes.
2. Portfolio Engineering for Full-Stack Developers
Software engineers building portfolio projects utilize public APIs to supply real-world data to their web and mobile applications. Integrating endpoints for live foreign exchange rates, weather telemetry, or geospatial mapping enables developers to demonstrate technical proficiency in managing asynchronous HTTP requests, state management, error handling, rate limit handling, and UI data rendering.
3. Educational Instruction and Technical Training
Computer science educators, bootcamp instructors, and technical authors rely on the public-apis directory to curate real-world API targets for classroom assignments, lab tutorials, and coding exercises. Students gain practical experience working with REST conventions, JSON payload parsing, HTTP response codes, and client-side authentication mechanisms using live public services.
4. Serverless Edge Proxy Integration
When a developer wishes to consume an endpoint listed with CORS: No or protect a private key for an Auth: apiKey entry, deploying a micro-proxy on serverless edge infrastructure (e.g., Cloudflare Workers, Node.js express server, or Vercel Edge Functions) provides a lightweight solution.
Example Node.js Express proxy routing requests to a target public API while adding CORS headers and securing an API key:
const express = require('express');
const axios = require('axios');
const app = express();
// Enable CORS headers for client applications
app.use((req, res, next) => {
res.header('Access-Control-Allow-Origin', '*');
res.header('Access-Control-Allow-Headers', 'Origin, X-Requested-With, Content-Type, Accept');
next();
});
// Proxy route hiding target credentials
app.get('/api/weather', async (req, res) => {
try {
const response = await axios.get('https://api.weatherservice.example/v1/forecast', {
params: {
city: req.query.city,
key: process.env.SECRET_API_KEY // Kept safe on server side
}
});
res.json(response.data);
} catch (error) {
res.status(500).json({ error: 'Failed to fetch upstream API data' });
}
});
app.listen(3000, () => console.log('Proxy server running on port 3000'));Comparative Analysis: Direct Client vs. Server-Proxied Integration Architecture
When selecting a public API from the catalog, developers must choose between connecting to the endpoint directly from the client application (e.g., browser or mobile client) or routing requests through a server-side proxy layer. The table below compares these two integration paradigms:
| Architectural Aspect | Direct Client Integration | Server-Proxied Integration | Operational Impact |
|---|---|---|---|
| CORS Dependency | Mandates CORS: Yes from the API host. |
Completely circumvents browser CORS checks. | Server proxies allow browser apps to consume CORS: No endpoints seamlessly. |
| API Key Security | Keys are exposed in client source code and network tools. | Keys remain securely stored in backend environment variables. | Server proxying is essential for protecting private API credentials from public exposure. |
| Network Latency | Single HTTP round-trip (Client → Public API). | Two HTTP round-trips (Client → Proxy Server → Public API). | Direct integration provides lower latency but sacrifices credential security. |
| Rate Limit Management | Rate limits enforced per client IP address. | Rate limits aggregated across the proxy server IP address. | Server proxies enable response caching to minimize total outbound calls to public APIs. |
| Implementation Overhead | Requires minimal code inside client-side scripts. | Requires building, deploying, and maintaining a backend service or serverless proxy. | Direct integration is ideal for quick prototypes; server proxying is required for production apps. |
Governance, Open-Source Licensing, and Community Ecosystem
The public-apis repository operates under open-source license standards (such as the Creative Commons CC0 1.0 Universal Public Domain Dedication or MIT License, as defined in project root metadata files). This allows developers, educators, and commercial organizations to freely consume, adapt, modify, and redistribute the dataset without license fees or legal restrictions.
Ongoing maintenance of the public-apis repository is carried out by a dedicated group of volunteer open-source maintainers. These maintainers review incoming pull requests, investigate issues reported by the developer community regarding altered service terms or dead links, and update automated continuous integration tooling. This active community oversight keeps the directory accurate, reliable, and resilient against web entropy—where external services periodically alter URL paths, change authentication tiers, or discontinue free public access.
Summary and Practical Resource Links
The public-apis repository remains an invaluable, community-maintained resource for modern web software engineering. By aggregating hundreds of free public endpoints into a standardized, machine-readable Markdown dataset complete with authentication, transport, and CORS security metadata, the project dramatically simplifies third-party web service discovery and architectural planning.
- GitHub Repository URL:
https://github.com/public-apis/public-apis - Primary Index File:
README.md - Validation Automation Suite: Located inside the project’s
scripts/directory.
What is the primary purpose of the public-apis repository?
The primary purpose of the public-apis repository is to maintain a community-driven, open-source catalog of free Application Programming Interfaces (APIs). It assists developers, software engineers, and researchers in rapidly discovering public endpoints for application development, educational research, and rapid prototyping. Every entry includes standardized metadata covering authentication requirements, HTTPS support, and CORS availability.
Are all APIs cataloged in the repository completely free of charge?
Every API cataloged within the repository offers a permanently free access tier or is completely open to the public without requiring initial payment credentials. However, individual API service providers may enforce usage quotas, rate limits, or require free account registration to obtain API keys. Developers should always review the target API provider’s official documentation for specific usage limits.
What does the Auth column signify in the API metadata table?
The Auth column specifies the authentication mechanism required to issue requests to a given service. Values include ‘No’ (no credentials required), ‘apiKey’ (requires an access key string), ‘OAuth’ (requires OAuth token authorization flows), or ‘User-Agent’ (requires specific HTTP client header fields).
Why is CORS support critical when selecting an API for web development?
Cross-Origin Resource Sharing (CORS) determines whether a web application running in a client browser (such as a React, Vue, or vanilla JavaScript application) can directly fetch data from an external API domain. If an API has ‘CORS: No’, browser security enforcement will block direct client-side requests. In such cases, developers must route requests through a backend server or proxy layer.
How can I submit a new API entry to the public-apis catalog?
To submit a new API entry, fork the public-apis repository on GitHub, locate the appropriate category table in the README.md file, and add your entry row in strict alphabetical order. Ensure all required metadata fields are accurately populated, execute the local Python validation script to confirm formatting compliance, and submit a Pull Request for maintainer review.
What checks are performed by the repository validation script?
The Python validation script (scripts/validate.py) automatically scans the README.md source file for correct Markdown table formatting, valid pipe alignment, alphabetical ordering of categories and entries, duplicate target links, valid HTTPS protocol formatting, and recognized enumeration values for Auth, HTTPS, and CORS fields.
How should broken links or offline APIs be reported?
If you discover a broken link, deprecated endpoint, or changed authentication policy, you can submit an Issue on the GitHub repository detailing the problem or submit a Pull Request directly to update or remove the non-functional entry. Maintainers regularly review community feedback to keep the index clean and accurate.
Can the public-apis catalog be consumed programmatically in custom tools?
Yes. Because the repository source is stored in standard, machine-readable Markdown tables under open-source licensing, developers can parse the raw README.md file directly or use community-maintained wrapper utilities to consume the directory dataset as JSON. This enables the creation of custom search portals, CLI discovery tools, and internal developer dashboards.
