TL;DR: if your Java app cannot send raw NACHA text through moov-io/ach's `POST /files/[fileID]` because the OpenAPI-generated client only exposes the JSON body schema (a long-standing openapi-generator limitation of one body schema per endpoint), use the dedicated raw-text endpoint added in PR #1653 (`POST /files/[fileID]/new`). The generator produces a method that takes a plain string body for it. The reporter confirmed this works for them.

## Steps

1. Use the dedicated endpoint for raw NACHA text:

```
POST /files/[fileID]/new
```

   with the raw NACHA text as the string body.

   Expected: the file is created from the raw text. Success check: the file reads back correctly.

2. Keep using the shared endpoint for JSON bodies; both paths now exist.

## When to use this

- Generated Java client cannot reach the raw-text code path on the shared endpoint.
- You need both JSON and raw-text creation.

## When NOT to use this

- JSON-body creation fails; that path is separate.
- You hand-write the HTTP calls; just send the raw text to the shared endpoint (the server now ignores Content-Type and tries both parsings).

## Compatibility

- moov-io/ach with PR #1653.

## Variant phrasings

- "moov ach java raw NACHA"
- "moov-io ach create file raw text endpoint"

## Root cause

The generator can only emit one body schema per endpoint, so the raw-text variant was unreachable from generated clients even after the server learned to parse both.

## Edge cases

- Hand-written clients do not need the new endpoint; the server-side Content-Type-agnostic parsing covers them.