docs/frontend-decisions.md

@@ -29,3 +29,22 @@ The portals live in an **Nx monorepo at the repository root**, alongside the .NE
 
 **NL Design System:** not yet introduced — the S-08a app is a placeholder. NL DS components arrive
 with the submit form (S-08c, #67); any deviation from NL DS will be recorded here.
+
+---
+
+## API client generator (S-08b, #66)
+
+`libs/api-client` is **generated from `services/bff/openapi.json`** — never hand-written (§10).
+
+- **Generator: orval** (`client: 'angular'`), a **node-based** generator (no Java, unlike
+  `openapi-generator`), so it runs in the pnpm/Node CI lane. It emits an injectable
+  `BffApiV1Service` using Angular's `HttpClient` — which means the DigiD bearer token can be attached
+  by an **`HttpInterceptor`** (S-08c), the idiomatic Angular approach; a fetch-based SDK would bypass
+  the interceptor pipeline.
+- **Config:** `libs/api-client/orval.config.ts` (single-file output into `src/lib/generated/`,
+  `clean: true`, prettier). **Regenerate with `nx run api-client:generate`** after the BFF spec
+  changes; the output is deterministic (idempotent), and `src/lib/generated/` is never hand-edited.
+- **Tested** against a mocked BFF via `HttpClientTesting` (`libs/api-client/src/lib/bff-api.spec.ts`).
+- The BFF endpoints carry no `operationId`, so orval synthesises method names
+  (`postSelfServiceRegistrations`, `getOpenbaarRegister`); adding explicit operation ids to the BFF
+  is a possible later polish.