FUSE Health Refund Requests API

Incoming patient-initiated refund-request triage. Approving a request moves real money.

GitHub OpenAPI

Operations 2

GET /api/v1/refund-requests List incoming patient refund requests for the clinic #
POST /api/v1/refund-requests/{id}/{action} Approve or deny a refund request (:action = approve|deny). #

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/fusehealth-com:fusehealth-com-refund-requests-api"
All apis
curl "https://apis.io/api/v1/apis?limit=25"

Calls without X-API-Key need no key. Calls with it need a paid plan — get a key.

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

fusehealth-com-refund-requests-api-openapi.yml Raw ↑
openapi: 3.2.0
info:
  title: FUSE Brand API (External) Refund Requests API
  version: 1.0.0
  description: 'Server-to-server API exposing the FUSE brand-admin surface so a single brand/tenant can build its own admin frontend. Every request is authenticated with an API key bound to exactly one clinic; all data is auto-scoped to that clinic and cannot reach another brand''s data. Isolation is enforced by application-layer clinic filtering on every query.


    COVERAGE: 218 operations across 180 paths, and EVERY ONE is available to every brand. There is no per-clinic enablement step. What governs access: your API key and its scopes, the clinic the key belongs to (every read and write is filtered to it), your plan''s entitlements for the two commercially-gated areas — Affiliates (`AFFILIATES_TIER_REQUIRED`) and CRM Connect (`CRM_TIER_REQUIRED`) — and rate limits.


    AUTH: the external /api/v1 surface uses an API key (`x-api-key`, ApiKeyAuth). Key management (/api-keys) and /auth/signin live at the API root and use a brand-admin JWT (BearerAuth); /auth/signin itself is unauthenticated.


    SCOPES: every key carries scopes; read-only is the default and mutating endpoints require the `write` scope (403 INSUFFICIENT_SCOPE otherwise). Keys default to a 1-year expiry.


    RATE LIMITING: every endpoint may additionally return `429 Too Many Requests` with a `Retry-After` header; 429 is not repeated on each operation below.


    PLATFORM FIELDS: product cost, fees, pharmacy routing, doctor questions and FUSE approvals are set by FUSE, not by the brand. Any write (POST/PUT/PATCH/DELETE) whose JSON body carries one of those fields at any depth — for example `pharmacyPrice`, `shippingFeeUsd`, `coolerFeeUsd`, `pharmacyId`, `preferredPharmacyId`, `pharmacyProvider`, `requiredDoctorQuestions`, `facilitationFee`, `placeholderPrice`, `legalBusinessName`, `isTemplate` or `tenantManagerApproved` — is refused with `403 PLATFORM_FIELD`, whose `fields` array lists the offending paths; remove them and resend. (One exception: `POST /api/v1/products` still accepts the `pharmacyPrice` its schema requires, and ignores it.) 403 PLATFORM_FIELD is not repeated on each operation below.'
servers:
- url: https://api-dev.fusehealth.com
  description: Development
- url: https://api.fusehealth.com
  description: Production
security:
- ApiKeyAuth: []
tags:
- name: Refund Requests
  description: Incoming patient-initiated refund-request triage. Approving a request moves real money.
paths:
  /api/v1/refund-requests:
    get:
      tags:
      - Refund Requests
      summary: List incoming patient refund requests for the clinic
      operationId: getApiV1Refundrequests
      description: List incoming patient refund requests for the clinic.
      security:
      - ApiKeyAuth: []
      parameters:
      - name: page
        in: query
        required: false
        schema:
          type: integer
          default: 1
        example: '1'
      - name: limit
        in: query
        required: false
        schema:
          type: integer
          default: 25
        example: '25'
      - name: status
        in: query
        required: false
        schema:
          type: string
        example: pending
      responses:
        '200':
          description: Success
          content:
            application/json:
              schema:
                type: object
                properties:
                  success:
                    type: boolean
                  message:
                    type: string
                  data: {}
        '401':
          $ref: '#/components/responses/Unauthorized'
  /api/v1/refund-requests/{id}/{action}:
    post:
      tags:
      - Refund Requests
      summary: Approve or deny a refund request (:action = approve|deny).
      operationId: postApiV1RefundrequestsByIdByAction
      description: Approve or deny a refund request (:action = approve|deny). Approve issues the refund.
      security:
      - ApiKeyAuth: []
      parameters:
      - name: id
        in: path
        required: true
        schema:
          type: string
      - name: action
        in: path
        required: true
        schema:
          type: string
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                reviewNotes:
                  type: string
            example:
              reviewNotes: Approved per policy
      responses:
        '200':
          description: Success
          content:
            application/json:
              schema:
                type: object
                properties:
                  success:
                    type: boolean
                  message:
                    type: string
                  data: {}
        '401':
          $ref: '#/components/responses/Unauthorized'
        '403':
          $ref: '#/components/responses/Forbidden'
        '404':
          $ref: '#/components/responses/NotFound'
components:
  responses:
    Forbidden:
      description: Authenticated but not permitted (insufficient scope, wrong role, or FUSE feature not enabled)
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/ErrorEnvelope'
    Unauthorized:
      description: Missing, invalid, inactive, or expired API key (or JWT)
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/ErrorEnvelope'
    NotFound:
      description: Resource not found (or not owned by the key's clinic)
      content:
        application/json:
          schema:
            $ref: '#/components/schemas/ErrorEnvelope'
  schemas:
    ErrorEnvelope:
      description: 'Failure shape. NOTE: most modules use `message`; programs endpoints use `error`. Read both. Some errors include a machine-readable `code` and/or a `data` payload.'
      type: object
      properties:
        success:
          type: boolean
          enum:
          - false
        message:
          type: string
        error:
          type: string
        code:
          type: string
        data: {}
  securitySchemes:
    ApiKeyAuth:
      type: apiKey
      in: header
      name: x-api-key
      description: Clinic-scoped API key. Keep server-side; never expose in a browser or app bundle.
    BearerAuth:
      type: http
      scheme: bearer
      bearerFormat: JWT
      description: FUSE brand-admin JWT (from POST /auth/signin). Used ONLY by the key-management endpoints — the external /api/v1 surface never accepts JWTs, and API keys never work on key management.