Integration Points and APIs

This document outlines the key integration points and Application Programming Interfaces (APIs) within the LCFS system.

1. Internal APIs (Backend Service)

• Provider: The backend service (FastAPI application).
• Type: RESTful APIs (confirmed by [fastapi-template.options] in pyproject.toml).
• Specification: FastAPI automatically generates an OpenAPI schema for the APIs it serves.
  • OpenAPI JSON: Typically available at the /openapi.json endpoint when the backend service is running.
  • Interactive API Docs (Swagger UI): Typically available at the /docs endpoint.
  • Interactive API Docs (ReDoc): Typically available at the /redoc endpoint.
• Consumers: Primarily the frontend React application. Other services or external clients could potentially consume these APIs if authorized.
• Authentication: Secured using JWTs, issued by Keycloak and validated by the backend (see Security Architecture).
• Key Functionality Areas (Inferred):
  • User management and authentication-related operations (though primarily delegated to Keycloak).
  • CRUD (Create, Read, Update, Delete) operations for core LCFS data entities.
  • Endpoints for business logic and workflow processing.
  • Endpoints for initiating asynchronous tasks via RabbitMQ.
  • Endpoints for file uploads/downloads via MinIO.

2. Frontend to Backend Communication

• The frontend (React application) uses the axios library to make HTTP requests to the backend APIs.
• It utilizes @tanstack/react-query for managing server state, which involves fetching, caching, and synchronizing data from these backend APIs.

3. External Service Integrations

3.1. Keycloak (Identity and Access Management)

• Purpose: Handles user authentication, identity brokering, and potentially fine-grained authorization.
• Integration Type: The frontend application integrates with Keycloak using OpenID Connect (OIDC) via keycloak-js and @react-keycloak/web libraries.
• Flow: The frontend redirects users to Keycloak for login. Keycloak issues JWTs (access and ID tokens) which are then used by the frontend to authenticate with the LCFS backend API.
• API Interaction: While primarily a redirect-based flow for authentication, Keycloak also has its own comprehensive set of APIs (Admin API, Account API) that LCFS might interact with for user management or other advanced scenarios (though this is not directly evident from current codebase analysis).

3.2. TFRS Database (ETL Source)

• Purpose: Acts as a data source for the ETL processes.
• Integration Type: The Apache NiFi service within the ETL subsystem connects to the TFRS PostgreSQL database using a JDBC connection.
• Data Flow: Data is extracted from TFRS and processed by NiFi for loading into the LCFS application database.

4. ETL Subsystem APIs/Interfaces

• Apache NiFi UI: Provides a web interface at http://localhost:8091/nifi/ (local dev) for managing, monitoring, and operating data flows.
• Apache NiFi REST API: NiFi itself exposes a comprehensive REST API that can be used to control and monitor NiFi programmatically. It's unclear if LCFS directly uses this API, but it's available.
• Apache NiFi Registry UI: Provides a web interface at http://localhost:18080 (local dev) for managing versioned flows.
• Apache NiFi Registry REST API: The NiFi Registry also has its own REST API.

Further Investigation

• Analyze the frontend code (services, API call locations) to map out specific backend API endpoints being consumed.
• Explore the /openapi.json schema (once the backend is running) to get a definitive list and structure of all backend APIs.
• Investigate NiFi flow definitions (etl/templates/) to understand the specifics of data interaction with the TFRS and LCFS databases.