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

# Get aggregate API availability

> Returns the current aggregate availability of the Flowlix API. This
operation is public and always returns HTTP 200 when the gateway can
answer. Inspect `status` instead of the HTTP status code.

`operational` means the required downstream connectivity evidence is
fresh and successful. `outage` means that evidence is missing, stale,
or failed. This aggregate status is not a per-operation SLA or a
guarantee that any individual transaction will succeed.




## OpenAPI

````yaml /api-reference/payments-api.yaml get /v1/health
openapi: 3.0.4
info:
  title: Flowlix Payments API
  version: 1.0.0
  description: >
    The Flowlix Payments API is a RESTful API for creating and retrieving

    Payments, creating Refunds, and submitting and retrieving Payouts.

    It follows industry-standard conventions: JSON request/response bodies,
    Bearer token authentication,

    standard HTTP verbs, idempotency support, and cursor-based pagination.


    ## Base URL


    API requests are made to `https://api.flowlix.eu`.

    Endpoints are versioned under `/v1`, e.g.

    `https://api.flowlix.eu/v1/payments`.


    ## Amounts and currencies


    All monetary amounts are expressed in **minor units** (the smallest currency
    unit).

    How many minor units make up one major unit is defined by the currency's

    ISO 4217 exponent, so the same integer means a different value in different

    currencies: `4999` is **EUR 49.99** and **GBP 49.99** (exponent 2), but

    **JPY 4999** (exponent 0, no minor unit). Do not assume two decimal places.


    Currencies are three-letter ISO 4217 codes. Requests are accepted

    case-insensitively; Flowlix normalizes them and always returns canonical

    uppercase codes such as `EUR`. The currencies accepted for a Payment or

    Payout are validated separately per request rather than listed in this

    contract, so enabling another currency is not a breaking change. A code

    that is not three letters is rejected with `400 parameter_invalid`

    (`param=currency`), and a well-formed code that Flowlix does not accept for

    the requested operation is rejected with `422 currency_not_supported`.

    Neither response creates a Payment or Payout.


    A refund is always made in the currency of the original payment, and the

    refund request does not accept a currency.
  contact:
    name: Flowlix Developer Support
    email: developers@flowlix.eu
    url: https://flowlix.dev/support
  license:
    name: Proprietary
    url: https://flowlix.dev/terms
servers:
  - url: https://api.flowlix.eu
    description: Flowlix Merchant API.
security:
  - BearerAuth: []
tags:
  - name: Health
    description: Check aggregate Flowlix API availability.
  - name: Payments
    description: Create, retrieve, and list payments.
  - name: Payouts
    description: Submit, list, and retrieve Host-to-Host card payouts.
  - name: Refunds
    description: >-
      Create refunds and track their status through the parent payment's
      `refunds` array.
paths:
  /v1/health:
    get:
      tags:
        - Health
      summary: Get aggregate API availability
      description: |
        Returns the current aggregate availability of the Flowlix API. This
        operation is public and always returns HTTP 200 when the gateway can
        answer. Inspect `status` instead of the HTTP status code.

        `operational` means the required downstream connectivity evidence is
        fresh and successful. `outage` means that evidence is missing, stale,
        or failed. This aggregate status is not a per-operation SLA or a
        guarantee that any individual transaction will succeed.
      operationId: getGatewayHealth
      responses:
        '200':
          description: Aggregate gateway availability at the reported check time.
          headers:
            Request-Id:
              $ref: '#/components/headers/RequestId'
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/GatewayHealth'
              examples:
                operational:
                  $ref: '#/components/examples/HealthOperational'
      security: []
components:
  headers:
    RequestId:
      description: >-
        A unique identifier for this API request. Include it when contacting
        support.
      schema:
        type: string
        maxLength: 255
      example: req_abc123def456
  schemas:
    GatewayHealth:
      type: object
      additionalProperties: false
      required:
        - status
        - checked_at
        - details
      properties:
        status:
          type: string
          enum:
            - operational
            - outage
          description: Aggregate API availability.
          example: operational
        checked_at:
          type: string
          format: date-time
          description: UTC timestamp when the gateway evaluated this response.
          example: '2026-08-05T12:34:56Z'
        details:
          type: object
          additionalProperties: true
          description: Aggregate availability details; empty when none are reported.
          example: {}
  examples:
    HealthOperational:
      summary: API is operational
      value:
        status: operational
        checked_at: '2026-08-24T12:34:56Z'
        details: {}
  securitySchemes:
    BearerAuth:
      type: http
      scheme: bearer
      description: |
        Use the secret API key for the intended merchant and mode as the Bearer
        token. Sandbox keys start with `api_test_sk_`. Send the key only from
        your server environment.

        ```
        Authorization: Bearer api_test_sk_abc123def456
        ```

````