List Reimbursements — Proposed Guide

Planned API — Reference Only

List Reimbursements: A reimbursement collection could help finance teams review pending and historical repayment records. Query results should not expose…

Overview

A reimbursement collection could help finance teams review pending and historical repayment records. Query results should not expose bank credentials or unrestricted beneficiary details.

Key concepts

Filter by explicit state and date boundaries. Follow cursors without changing organization context.

Implementation considerations

A listed completed record must have a defined evidence basis in any future service. The sample completed state is fictional, not a transaction confirmation.

Proposed API behavior

GET /v1/reimbursements is an illustrative design for this topic. Path and field names may change before implementation. Access would require an authorized organization context and operation-specific permission; no public API or authorization grant is available here.

Illustrative query parameters
Name	Type	Description
status	string	Proposed lifecycle value. Its meaning depends on the resource and must not be inferred from HTTP success.
start_date	string (date)	Synthetic calendar date in YYYY-MM-DD form; period inclusivity must be defined by the future contract.
end_date	string (date)	Synthetic calendar date in YYYY-MM-DD form; period inclusivity must be defined by the future contract.
limit	integer	Requested collection size. This example is not a promised service limit.
cursor	string	Opaque fictional continuation value; retain the original filters when following it.

Static example requests

Proposed, non-executing request examples

# Proposed request text only; this reserved host is not a live API.
curl -X GET 'https://api.remizen.example/v1/reimbursements?status=draft&start_date=2026-01-15&end_date=2026-01-31&limit=25&cursor=cursor_example_123' \
  -H 'Authorization: Bearer YOUR_API_KEY'

Fictional response example

200 (proposed example)Static response fixture

Fictional documentation data only. No request was sent, record created, review performed, payment initiated or provider connection activated.

JSON

{
  "data": [
    {
      "id": "reimb_example_123",
      "organization_id": "org_example_123",
      "expense_ids": [
        "exp_example_123"
      ],
      "amount_minor": 12550,
      "currency": "USD",
      "status": "draft"
    }
  ],
  "pagination": {
    "has_more": false,
    "next_cursor": null
  },
  "meta": {
    "request_id": "req_example_123",
    "reference_only": true
  }
}

Illustrative error case

Review this failure case in context: A listed completed record must have a defined evidence basis in any future service. The sample completed state is fictional, not a transaction confirmation.

422 (illustrative; final error contracts are undecided)Proposed error fixture

Synthetic diagnostic example. Human-readable messages must not be used as stable programmatic contracts.

JSON

{
  "error": {
    "code": "validation_error",
    "message": "The proposed list reimbursements operation requires review of its input or authorization.",
    "request_id": "req_example_123"
  }
}

Proposed data types

Illustrative field dictionary
Name	Type	Description
status	string	Proposed lifecycle value. Its meaning depends on the resource and must not be inferred from HTTP success.
start_date	string (date)	Synthetic calendar date in YYYY-MM-DD form; period inclusivity must be defined by the future contract.
end_date	string (date)	Synthetic calendar date in YYYY-MM-DD form; period inclusivity must be defined by the future contract.
limit	integer	Requested collection size. This example is not a promised service limit.
cursor	string	Opaque fictional continuation value; retain the original filters when following it.

Reimbursements API Overview

Reimbursements & Payments

Retrieve Reimbursement