# Workflows

Exported as JSON and committed. The n8n instance is not the source of truth.

## Importing

n8n's REST API, with an owner session cookie. The activation endpoint is
separate from the update one and requires the current `versionId`:

```
POST  /rest/workflows                      # import
POST  /rest/workflows/<id>/activate        # {"versionId": "<current>"}
```

`PATCH /rest/workflows/<id>` with `{"active": true}` returns 200 and leaves the
workflow inactive, silently. Use the activate endpoint.

## approvisionnement-check-availability

**Not working yet.** The `Exchange token` node fails, and what it fails with is
worth recording:

```
Keycloak 500, an HTML login page as the body
NullPointerException: Cannot invoke UserSessionModel.getAuthenticatedClientSessionByClient
  because "userSession" is null
  at V1TokenExchangeProvider.exchangeClientToOIDCClient
```

Two things stand out. Keycloak answers a malformed token exchange with a **500
and a rendered login page**, which tells a client nothing. And it took the **V1**
exchange path, not the Standard one every other agent in this estate uses
successfully.

What has been eliminated, each by hand against the same running Keycloak:

- the client and its secret — Keycloak logs
  `kc.clientId: classic-models-agent-approvisionnement`, so it authenticated,
  which also proves `$env` reaches the node
- the subject token — the *same* token replayed with curl exchanges fine (200)
- omitting `subject_token_type` — still 200
- omitting `openid` from the scope — still 200
- using `audience=` instead of a scope — a clean 400, not this

So n8n is sending something the reproduction attempts are not. The next step is
to capture the request as the node actually emits it: point the node at an
in-cluster echo service and read the body. That was set up and the run did not
reach it, which is itself unexplained and where this stopped.