> ## Documentation Index
> Fetch the complete documentation index at: https://documentation.incaseof.law/llms.txt
> Use this file to discover all available pages before exploring further.

# Health check

> Whether the API is up. Needs no API key — the `Authorization` header is ignored here.



## OpenAPI

````yaml get /health
openapi: 3.0.3
info:
  title: incaseof.law Partner API
  version: 1.0.0
  description: >
    The incaseof.law partner API (`/openapi/*`): create claims and debtors,
    attach invoices and documents, record

    payments, follow a claim through collection and take the judicial-step
    decision.


    This document is the contract the API is tested against: every path, request
    body and response field here is

    compared with the implementation on each change. A field that is not listed
    here is not part of the API.


    ## Authentication


    Every `/openapi` request carries `Authorization: Bearer <api key>`. API keys
    are opaque strings starting with

    `ico_live_` (not JWTs). Request a key at https://app.incaseof.law/openapi;
    incaseof.law reviews the request and

    sends the key by e-mail.


    - **Organisation keys** act for one creditor organisation.

    - **Partner keys** act for a partner (software vendor, reseller) and its
    customers. Requests that create a claim
      or a debtor name the customer with `customer_id`; reads and updates reach every object of the partner's own
      customers without it. A `customer_id` that does not exist answers `400`, one of another partner `403`.

    ## Errors


    Every error answers `{ "success": false, "message": "…" }`, some with an
    `error` code. Validation errors list the

    failed fields in `details` (see `BadRequest`). Every response carries the
    rate-limit headers (see

    `TooManyRequests`).


    ## Webhooks


    incaseof.law can push events to a partner-controlled HTTPS endpoint whenever
    a claim's lifecycle changes:

    `claim.collection_stage_changed` and `claim.status_changed`. See the
    **Webhooks** section at the bottom of this

    document for the payload shape, header reference, signature scheme and retry
    policy.
servers:
  - url: https://service.incaseof.law
    description: Production API
  - url: https://ico-app-staging.up.railway.app
    description: Partner sandbox (test data only, sandbox keys — see "Partner sandbox")
security:
  - bearerAuth: []
tags:
  - name: Health
    description: Service availability
  - name: Claims
    description: Claims, their status and the judicial-step decision
  - name: Debtors
    description: Debtors of your claims
  - name: Invoices
    description: The invoices a claim is based on
  - name: Payments
    description: Payments the debtor made
  - name: Documents
    description: Supporting documents of a claim
  - name: Customers
    description: A partner's customers (the creditors it works for)
paths:
  /health:
    get:
      tags:
        - Health
      summary: Health check
      description: >-
        Whether the API is up. Needs no API key — the `Authorization` header is
        ignored here.
      operationId: getHealth
      responses:
        '200':
          description: OK
          content:
            application/json:
              schema:
                type: object
                properties:
                  status:
                    type: string
                    example: ok
                  timestamp:
                    type: string
                    format: date-time
                  service:
                    type: string
                    example: ico-api
                  version:
                    type: string
      security:
        - {}
components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      description: >-
        An API key (`ico_live_…`), sent as `Authorization: Bearer <key>`. Not a
        JWT.

````

This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.