List Transactions

Lists transactions for the authenticated exchange app with optional filtering and pagination. **Authentication:** - **REQUIRED**: Provide client_id and client_secret via: - Basic Auth: `Authorization: Basic base64(client_id:client_secret)` - The `exchange_app_id` is automatically derived from authenticated credentials (not accepted as query parameter) **Query Parameters:** - `status` (optional): Filter by transaction status (PENDING, PROCESSING, SUCCESS, FAILED) - `limit` (optional): Number of transactions to return (1-100, default: 50) - `start_after` (optional): Transaction ID to start after for pagination (cursor-based pagination) - `start_date` (optional): Start date for date range filter (ISO 8601 format, e.g., '2024-01-01T00:00:00Z'). Filters transactions where `created_at >= start_date` - `end_date` (optional): End date for date range filter (ISO 8601 format, e.g., '2024-01-31T23:59:59Z'). Filters transactions where `created_at <= end_date` - `detail` (optional): `full` returns the legacy wide transaction objects (full `qr_data`, duplicate flat recipient columns). **Default is slim** (smaller payload per row). **Date Range Filtering:** - Both `start_date` and `end_date` are optional and can be used independently or together - Dates must be in ISO 8601 format (e.g., '2024-01-01T00:00:00Z') - If both dates are provided, `start_date` must be before or equal to `end_date` - Date range filtering is based on the transaction's `created_at` timestamp - Date range can be combined with status filtering **Response:** - `transactions`: Array of sanitized transaction objects - `total`: Number of transactions returned - `limit`: Limit used - `has_more`: Whether there are more transactions available - `next_cursor`: Transaction ID to use as start_after for next page (if has_more is true) **Sanitization:** Each transaction object is sanitized: `provider` and `provider_tx_id` are removed, and fields whose names start with `_` (internal server-only data) are never returned. **Note:** Transactions are ordered by `created_at` in descending order (most recent first). When filtering by status, a composite index is required in Firestore. When filtering by date range with status, a composite index is required.