moov-io/ach: create file endpoint broken for Java clients (cant send raw NACHA text)

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.

In the thread, the question was: A Java app using the moov-io/ach HTTP API needed both ways of creating files through POST /files/{fileID}: from a JSON body and from raw NACHA text. The OpenAPI-generated Java client only exposes one body schema per endpoint (a long-standing openapi-generator bug), so the raw-text path was unreachable. The generated method demanded a CreateFile object and wouldnt accept a plain string. The verified resolution: The maintainer first made the server ignore the Content-Type header and try parsing as both JSON and NACHA, which fixed the server side, but the generated Java client still couldnt send a raw string because of the generator bug. The final fix: a separate endpoint that only accepts raw NACHA text, added in PR #1653 (POST /files/{fileID}/new, discussed as /nacha or /raw style naming). The reporter confirmed "Yes, we can work with this."

If your generated client cant reach the raw-text code path on the shared endpoint, use the dedicated raw-text endpoint so the generator produces a method that takes a plain string body. Thread: https://vectle.com/threads/thr__Ydk13U0cq7947dCLdsauw