EpicDirectories Health API

The health API from EpicDirectories — 2 operation(s) for health.

Operations 2

GET /v1/health Health check (liveness) — always 200 while the process is up #
GET /v1/health/ready Readiness — 503 when a dependency is down #

Work with this as data

Every API here is available over the APIs.io API and to AI agents over MCP.

MCP server

One button, every client — Claude, Cursor, VS Code and the rest.

https://apis.io/mcp

Tools for apis

7 MCP tools reach this
  • find_apisBrowse and filter every API in the catalog.
  • get_api_artifactsOne API's artifacts, grouped by type.
  • get_openapiThe primary OpenAPI for this API.
  • find_similar_apisAPIs that look like this one.
  • apis_io_searchSTART HERE — APIs, providers and tags for one query, each with its total.
  • resolveTurn a domain, URL or GitHub org into the provider it belongs to.
  • find_cohortsEvery scored population of providers in the catalog.
All 92 tools →

Call it yourself

curl for this page
This API
curl "https://apis.io/api/v1/apis/epicdirectories:epicdirectories-health-api"
All apis
curl "https://apis.io/api/v1/apis?limit=25"

Discovery needs no key. Ratings and market analysis are Pro.

Get an API key

Free tier, no form to fill in. Signing in shares your email address with us — we store it to create your key and to recognise you if you sign in with another provider. See our Privacy Policy and Terms.

A second provider on the same verified email joins the account you already have.

OpenAPI Specification

epicdirectories-health-api-openapi.yml Raw ↑
openapi: 3.2.0
info:
  title: EpicDirectories Health API
  description: API-first directory data platform.
  version: '1.0'
  contact: {}
servers:
- url: https://api.epicdirectories.com
  description: Production
- url: http://localhost:3333
  description: Local development
tags:
- name: Health
paths:
  /v1/health:
    get:
      operationId: HealthController_check
      summary: Health check (liveness) — always 200 while the process is up
      description: 'Render polls this, so it deliberately **does not** fail on a broken dependency: the API serves reads perfectly well with Redis down, and returning non-200 would get the service restarted, turning a queue outage into a total one.


        Read `status` (`ok` | `degraded`) and `alerts[]` instead of the HTTP code. `alerts` names any queue carrying failed jobs — the signal that was missing when every media job failed silently for months behind a green check.


        For something that pages, use `/v1/health/ready`, which 503s when a dependency is down.'
      parameters: []
      responses:
        '200':
          description: Process is up; body reports dependency status
      tags:
      - Health
  /v1/health/ready:
    get:
      operationId: HealthController_ready
      summary: Readiness — 503 when a dependency is down
      description: 'Same probes as `/v1/health`, but the HTTP status reflects them, so an uptime monitor can alert without parsing the body. **Do not point a platform health check at this** — a suspended Redis would restart-loop the API for no benefit.


        Failed *jobs* do not 503: those are a data or upstream problem, not a reason to declare the service unfit. They appear in `alerts[]`.'
      parameters: []
      responses:
        '200':
          description: All dependencies reachable
        '503':
          description: Database or Redis unreachable; body lists what
      tags:
      - Health
components:
  securitySchemes:
    bearer:
      scheme: bearer
      bearerFormat: JWT
      type: http
    apiKey:
      type: apiKey
      in: header
      name: x-api-key