InboxGuard System API

openapi: 3.2.0
info:
  title: InboxGuard System API
  version: 1.2.0
  summary: Email deliverability monitoring, DMARC reporting, and DNS authentication scanning.
  description: 'The InboxGuard REST API lets developers and AI agents run on-demand deliverability scans (SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI, and DNS blocklists), re-verify raw email headers, manage monitored domains, read DMARC aggregate reports, list alerts, and manage API keys.


    ## Authentication

    Authenticated endpoints accept an InboxGuard API key as a bearer token:


    ```

    Authorization: Bearer ig_live_xxxxxxxxxxxxxxxxxxxxxxxx

    ```


    Mint keys in the dashboard (Settings → API keys) or via `POST /api-keys`. Keys carry scopes: `read` (GET only) or `full` (all methods). See https://inboxguard.io/auth.md.


    ## Errors

    Every error returns the same structured envelope (`#/components/schemas/Error`): `{ "error": { "code": "RATE_LIMIT", "message": "...", "requestId": "..." } }`.


    ## Rate limits

    The anonymous `POST /scan-domain` endpoint allows 5 requests/hour per IP; authenticated callers get their plan''s hourly limit. `POST /scan-domain` responses carry `RateLimit-Limit`, `RateLimit-Remaining`, `RateLimit-Reset` (and `X-RateLimit-*` equivalents); 429 responses add `Retry-After`.


    ## Idempotency

    `POST /scan-domain` accepts an optional `Idempotency-Key` header with real replay semantics: a retry with the same key from the same caller within 1 hour returns the stored response instead of re-running the scan, marked with an `Idempotency-Replayed: true` response header.


    ## Versioning

    The API uses unversioned, stable URLs (one surface — no `/v1` path prefix). The current API version is echoed on every response in the `API-Version` header. Additive, backward-compatible changes (new endpoints, new optional fields) ship continuously without a version bump. Breaking changes — when they are ever needed — ship under a NEW version that you opt into by sending an optional `Accept-Version` request header; the existing behaviour remains the default so unversioned callers are never broken. Omit `Accept-Version` to always get the current stable version. Upcoming breaking changes are announced in these docs and at https://inboxguard.io/llms-full.txt in advance.


    ## Pagination

    Only `GET /scans` is paginated: pass `?before=` (from the previous response''s `nextCursor`) to walk older scans. `GET /domains`, `GET /alerts`, and `GET /api-keys` return the full (limit-capped) list in one response — there are no `cursor` parameters.'
  termsOfService: https://inboxguard.io/terms
  contact:
    name: InboxGuard Support
    email: support@inboxguard.io
    url: https://inboxguard.io/contact
  license:
    name: Proprietary
    url: https://inboxguard.io/terms
  x-deprecation-policy: 'Unversioned, stable URLs. When an endpoint or field is ever deprecated, responses carry a ''Deprecation: true'' header and a ''Sunset: <HTTP-date>'' header marking the removal date — at least 6 months out — plus a ''Link: <url>; rel="deprecation"'' pointer to migration notes. Opt into a future breaking version with the optional ''Accept-Version'' request header. Nothing is deprecated today.'
servers:
- url: https://api.inboxguard.io
  description: Production
security:
- ApiKeyBearer: []
tags:
- name: System
  description: Health and status.
paths:
  /health:
    get:
      operationId: getHealth
      tags:
      - System
      summary: Liveness and database connectivity probe
      description: Unauthenticated. Returns service status and database connectivity.
      security: []
      parameters:
      - $ref: '#/components/parameters/AcceptVersion'
      responses:
        '200':
          description: Service healthy
          headers:
            API-Version:
              $ref: '#/components/headers/ApiVersion'
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Health'
              example:
                status: ok
                db: ok
                durationMs: 7
                env: production
                version: a1b2c3d
        '503':
          description: 'Service degraded (database unreachable). Note: this probe returns the `Health` schema (with `db: "error"`), NOT the error envelope.'
          headers:
            API-Version:
              $ref: '#/components/headers/ApiVersion'
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Health'
        '500':
          $ref: '#/components/responses/InternalServerError'
components:
  headers:
    ApiVersion:
      description: The API version that served this response. The URL surface is unversioned and stable; this header reports the current version so clients can detect breaking-change rollouts. Send the optional `Accept-Version` request header to pin a version once a future breaking version is published.
      schema:
        type: string
  responses:
    InternalServerError:
      description: Unexpected server error. Any unhandled failure is normalised by the root middleware into the structured error envelope with code `INTERNAL_ERROR` and a `requestId` for support.
      headers:
        API-Version:
          $ref: '#/components/headers/ApiVersion'
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/Error'
          example:
            error:
              code: INTERNAL_ERROR
              message: Internal server error
              requestId: 9f8c1b2a-3d4e-4f5a-8b6c-7d8e9f0a1b2c
  schemas:
    Health:
      type: object
      properties:
        status:
          type: string
          enum:
          - ok
          - degraded
        db:
          type: string
          enum:
          - ok
          - error
        dbError:
          type: string
          description: Present when db = error.
        durationMs:
          type: integer
        env:
          type: string
        version:
          type: string
      required:
      - status
      - db
    Error:
      type: object
      description: Structured error envelope returned by every non-2xx response.
      properties:
        error:
          type: object
          properties:
            code:
              type: string
              description: Stable machine-readable code.
              enum:
              - BAD_REQUEST
              - UNAUTHORIZED
              - FORBIDDEN
              - NOT_FOUND
              - CONFLICT
              - RATE_LIMIT
              - UPSTREAM_ERROR
              - INTERNAL_ERROR
              - SERVICE_UNAVAILABLE
              - DNS_TEMPORARY_FAILURE
            message:
              type: string
              description: Human-readable description.
            requestId:
              type: string
              description: Correlation id for support.
            details:
              description: Optional structured validation detail (e.g. zod field errors).
            retryAfterSeconds:
              type: integer
              description: Present on RATE_LIMIT responses.
          required:
          - code
          - message
      required:
      - error
  parameters:
    AcceptVersion:
      name: Accept-Version
      in: header
      required: false
      description: Optional API version opt-in. Omit to receive the current stable version (recommended). Send a specific version string only to opt into a future breaking-change version once one is published; unknown values fall back to the current stable version. The version actually served is echoed in the `API-Version` response header.
      schema:
        type: string
  securitySchemes:
    ApiKeyBearer:
      type: http
      scheme: bearer
      bearerFormat: InboxGuard API key (ig_live_… / ig_test_…)
      description: 'PRIMARY auth: send an InboxGuard API key as a bearer token (`Authorization: Bearer ig_live_…`). Scopes: `read` (GET) and `full` (all methods). Mint a key at https://inboxguard.io/settings or per https://inboxguard.io/auth.md.'
    OAuth2:
      type: oauth2
      description: 'OAuth-shaped wrapper around the same API key. The ONLY grant is client_credentials at POST https://api.inboxguard.io/oauth/token, where the client_secret IS an InboxGuard API key (HTTP Basic or body); the returned access_token is that same key. There is NO authorization_code flow, NO PKCE, and NO /oauth/authorize endpoint. Discovery: /.well-known/oauth-authorization-server and /.well-known/oauth-protected-resource on api.inboxguard.io. See https://inboxguard.io/auth.md.'
      flows:
        clientCredentials:
          tokenUrl: https://api.inboxguard.io/oauth/token
          scopes:
            read: Read-only access (GET).
            full: Full read/write access (all methods).
externalDocs:
  description: API quickstart and guides
  url: https://inboxguard.io/guides/api-quickstart