freqblog-com System API

openapi: 3.2.0
info:
  title: Freqblog Com System API
  version: 1.5.0
  contact:
    name: FreqBlog
    url: https://freqblog.com/
    email: hello@freqblog.com
  license:
    name: Commercial — see freqblog.com/terms.html
    url: https://freqblog.com/terms.html
  description: 'Operations tagged System across 2 of this provider''s published API definitions: freqblog-com-openapi.json, freqblog-com-openapi1.json. Each path carries the servers of the definition it was published in.'
servers:
- url: https://api.freqblog.com
  description: Production
security:
- APIKeyHeader: []
tags:
- name: System
  description: Health and operational endpoints
paths:
  /me/webhook:
    get:
      tags:
      - System
      summary: Get the webhook URL configured for your API key
      operationId: get_webhook_me_webhook_get
      parameters:
      - name: x-api-key
        in: header
        required: false
        schema:
          type: string
          title: X-Api-Key
      responses:
        '200':
          description: Successful Response
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/WebhookStatus'
        '422':
          description: Validation Error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/HTTPValidationError'
    post:
      tags:
      - System
      summary: Set or update the webhook URL for your API key
      description: 'Configure a webhook URL to be POSTed when your on-demand ingests and field-fill backfills complete — so a pipeline is pushed the result instead of polling or reading the email.


        **Events** (`type` / `X-FreqBlog-Event`): `ingest.completed`, `ingest.failed` (on-demand `/lookup` misses), and `backfill.completed` (field-fill). Ingest events carry a `result_url` you can GET for the full feature set.


        **Payload example** (JSON):

        ```json

        { "type": "ingest.completed", "status": "completed", "track_name": "...", "artist_name": "...", "job_id": 123, "timestamp": "2026-07-14T19:00:00Z", "result_url": "https://api.freqblog.com/lookup?track=..." }

        ```


        **`ingest.failed` adds a machine-readable why** — so you can retry what is worth retrying and stop re-queueing what is not, instead of applying one flat backoff to everything:

        ```json

        { "type": "ingest.failed", "status": "failed", "track_name": "...", "artist_name": "...", "job_id": 123, "timestamp": "2026-08-02T07:00:00Z", "result_url": "...", "terminal": true, "reason": "not_on_streaming", "retry_after_days": 7, "message": "We couldn''t find a recording matching this title and artist on the streaming catalogues we search — ..." }

        ```

        `terminal: true` means the verdict will not change until `retry_after_days` has elapsed — stop re-polling that track until then. `terminal: false` means the failure was transient and the track is worth another attempt (we also retry it ourselves). `message` is the human sentence, for logs and support; branch on `reason`, never on `message`. `retry_after_days` is present only when `terminal` is true.


        | `reason` | terminal | meaning |

        |---|---|---|

        | `not_on_streaming` | yes | No acceptable match in the streaming catalogues we search — CD-only, unreleased, off-streaming or very-regional. Upload the file to `POST /analyze` if you hold it yourself. |

        | `no_preview_audio` | yes | Matched, but the release carries no 30-second preview clip, and features are computed from preview audio. |

        | `throttled` | no | A music source rate-limited **us**, not a problem with the track. |

        | `cdn_forbidden` | no | The preview URL was refused by its CDN and no fallback source had it. |

        | `download_failed` | no | The preview fetch failed before analysis. |

        | `analysis_failed` | no | Audio downloaded, but analysis did not complete. |

        | `internal_error` | no | Our fault. Retry. |


        ⚠ `not_on_streaming` / `no_preview_audio` are the **same strings** a terminal `/lookup` 404 returns in its own `reason` field, with the same `terminal` and `retry_after_days` semantics — one branch in your client handles both surfaces. Treat the list as open: a future release may add a `reason`, so default unknown values to ''retry later'' rather than rejecting the delivery.


        **Signature verification**: each POST carries `X-FreqBlog-Timestamp` and `X-FreqBlog-Signature: sha256=`, where the hex is `HMAC-SHA256(secret, X-FreqBlog-Timestamp + ''.'' + rawBody)` and `secret = SHA256(key_hash)` where `key_hash = SHA256(your_plaintext_api_key)` (i.e. SHA-256 applied twice, both as lowercase hex). Recompute it, constant-time compare, and reject a timestamp older than ~5 minutes (replay guard).


        **URL must be a public HTTPS host** (private/loopback/link-local addresses are refused). Call DELETE to clear.


        **Delivery + retries**: up to 3 attempts per event (immediately, then +2s, +6s), 8s timeout, any `2xx` = delivered. A `4xx` other than `429` is treated as permanent and is NOT retried — return `5xx`/`429` for anything you want redelivered. After 15 consecutive failures we pause delivery, then send one probe event per hour; the first probe you answer `2xx` resumes normal delivery (no need to re-register). Treat webhooks as a signal to fetch, not your only copy — every ingest lands in the catalog regardless, so `/lookup` always returns the record.'
      operationId: set_webhook_me_webhook_post
      parameters:
      - name: x-api-key
        in: header
        required: false
        schema:
          type: string
          title: X-Api-Key
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/WebhookConfig'
      responses:
        '200':
          description: Successful Response
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/WebhookStatus'
        '422':
          description: Validation Error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/HTTPValidationError'
    delete:
      tags:
      - System
      summary: Clear the webhook URL for your API key
      operationId: delete_webhook_me_webhook_delete
      parameters:
      - name: x-api-key
        in: header
        required: false
        schema:
          type: string
          title: X-Api-Key
      responses:
        '200':
          description: Successful Response
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/WebhookStatus'
        '422':
          description: Validation Error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/HTTPValidationError'
    servers:
    - url: https://api.freqblog.com
      description: Production
  /me/stats:
    get:
      tags:
      - System
      summary: Usage statistics for your API key
      description: Return detailed usage statistics for the authenticated API key.
      operationId: me_stats_me_stats_get
      parameters:
      - name: x-api-key
        in: header
        required: false
        schema:
          type: string
          title: X-Api-Key
      responses:
        '200':
          description: Successful Response
          content:
            application/json:
              schema: {}
        '422':
          description: Validation Error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/HTTPValidationError'
    servers:
    - url: https://api.freqblog.com
      description: Production
  /me/preferences:
    get:
      tags:
      - System
      summary: Notification preferences for your API key
      description: Read the current ingest/backfill email preference.
      operationId: me_preferences_me_preferences_get
      parameters:
      - name: x-api-key
        in: header
        required: false
        schema:
          type: string
          title: X-Api-Key
      responses:
        '200':
          description: Successful Response
          content:
            application/json:
              schema: {}
        '422':
          description: Validation Error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/HTTPValidationError'
    servers:
    - url: https://api.freqblog.com
      description: Production
  /me/preferences/ingest_emails:
    post:
      tags:
      - System
      summary: Toggle ingest/backfill email notifications
      description: 'Flip ingest/backfill emails on or off for every active key sharing this

        label. The dashboard''s Recent Activity panel is the in-app channel when

        emails are off.'
      operationId: me_preferences_ingest_emails_me_preferences_ingest_emails_post
      parameters:
      - name: enabled
        in: query
        required: true
        schema:
          type: boolean
          description: True to receive emails for on-demand ingest and backfill completions; false to silence them. Welcome, billing, security, and quota emails are unaffected.
          title: Enabled
        description: True to receive emails for on-demand ingest and backfill completions; false to silence them. Welcome, billing, security, and quota emails are unaffected.
      - name: x-api-key
        in: header
        required: false
        schema:
          type: string
          title: X-Api-Key
      responses:
        '200':
          description: Successful Response
          content:
            application/json:
              schema: {}
        '422':
          description: Validation Error
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/HTTPValidationError'
    servers:
    - url: https://api.freqblog.com
      description: Production
  /health:
    get:
      tags:
      - System
      summary: Health check
      operationId: health_health_get
      responses:
        '200':
          description: Successful Response
          content:
            application/json:
              schema: {}
    servers:
    - url: https://api.freqblog.com
      description: Production
  /health/lookup:
    get:
      tags:
      - System
      summary: Data-path health check (live lookup probe)
      description: Goes one level deeper than `/health` — runs an internal lookup for a known-good catalog track and returns 200 only if features come back. Use this with UptimeRobot (or any external probe) to alert on data-path regressions, not just process-up. No auth required. Counts as zero quota against any key.
      operationId: health_lookup_health_lookup_get
      responses:
        '200':
          description: Successful Response
          content:
            application/json:
              schema: {}
    servers:
    - url: https://api.freqblog.com
      description: Production
  /health/backfill-worker:
    get:
      tags:
      - System
      summary: Backfill worker health check
      description: Check if the background backfill worker is healthy and queue status.
      operationId: backfill_worker_health_health_backfill_worker_get
      responses:
        '200':
          description: Successful Response
          content:
            application/json:
              schema: {}
    servers:
    - url: https://api.freqblog.com
      description: Production
  /health/deep:
    get:
      tags:
      - System
      summary: Deep health check — write path + WAL + worker liveness
      description: 'Integration probe for monitoring (UptimeRobot keyword="ok"). Returns 200 ONLY when all green: SQLite write path responds in <2s + the CATALOGUE READ path answers + all configured backfill workers alive. Returns 503 + status="error" if the write path is wedged (the 2026-05-25 failure mode — uvicorn alive, /lookup writes timing out), the catalogue read path is broken (the 2026-08-27 failure mode — a schema change the running code did not expect, which this endpoint missed for 20 consecutive checks before `catalog_read` was added), or zero workers alive. Returns 200 + status="warning" + non-empty `issues` for soft degradation (some workers down). `checks.wal_size_mb` is reported for information but does NOT affect `status` (2026-07-26 — it is a proxy metric; wal_watchdog owns alerting on it). No auth required. Counts as zero quota.'
      operationId: health_deep_health_deep_get
      responses:
        '200':
          description: Successful Response
          content:
            application/json:
              schema: {}
    servers:
    - url: https://api.freqblog.com
      description: Production
  /cache/stats:
    get:
      tags:
      - System
      summary: Cache statistics
      operationId: cache_stats_cache_stats_get
      responses:
        '200':
          description: Successful Response
          content:
            application/json:
              schema: {}
    servers:
    - url: https://api.freqblog.com
      description: Production
components:
  schemas:
    ValidationError:
      properties:
        loc:
          items:
            anyOf:
            - type: string
            - type: integer
          type: array
          title: Location
        msg:
          type: string
          title: Message
        type:
          type: string
          title: Error Type
      type: object
      required:
      - loc
      - msg
      - type
      title: ValidationError
    HTTPValidationError:
      properties:
        detail:
          items:
            $ref: '#/components/schemas/ValidationError'
          type: array
          title: Detail
      type: object
      title: HTTPValidationError
    WebhookStatus:
      properties:
        url:
          anyOf:
          - type: string
          - type: 'null'
          title: Url
          description: Current webhook URL, or null if none configured.
        signing_note:
          type: string
          title: Signing Note
          description: How to verify webhook authenticity.
          default: 'Each POST carries X-FreqBlog-Timestamp and X-FreqBlog-Signature: sha256=<hex>, where the hex is HMAC-SHA256(secret, X-FreqBlog-Timestamp + ''.'' + rawBody) and secret = SHA256(SHA256(your_plaintext_api_key)). Recompute + constant-time compare, and reject a timestamp older than ~5 minutes (replay guard).'
      type: object
      title: WebhookStatus
    WebhookConfig:
      properties:
        url:
          type: string
          maxLength: 500
          minLength: 8
          title: Url
          description: HTTPS URL where backfill notifications will be POSTed.
          examples:
          - https://example.com/freqblog-webhook
      type: object
      required:
      - url
      title: WebhookConfig
    WebhookStatus_2:
      properties:
        url:
          type:
          - string
          - 'null'
          title: Url
          description: Current webhook URL, or null if none configured.
        signing_note:
          type: string
          title: Signing Note
          description: How to verify webhook authenticity.
          default: 'Each POST carries X-FreqBlog-Timestamp and X-FreqBlog-Signature: sha256=<hex>, where the hex is HMAC-SHA256(secret, X-FreqBlog-Timestamp + ''.'' + rawBody) and secret = SHA256(SHA256(your_plaintext_api_key)). Recompute + constant-time compare, and reject a timestamp older than ~5 minutes (replay guard).'
      type: object
      title: WebhookStatus
    WebhookConfig_2:
      properties:
        url:
          type: string
          maxLength: 500
          minLength: 8
          title: Url
          description: HTTPS URL where backfill notifications will be POSTed.
          example: https://example.com/freqblog-webhook
      type: object
      required:
      - url
      title: WebhookConfig
  securitySchemes:
    APIKeyHeader:
      type: apiKey
      in: header
      name: X-Api-Key
x-refined-from:
- freqblog-com-openapi.json
- freqblog-com-openapi1.json