Automating NACHA File Generation via API

Excel is useful for an occasional payment run, but it should not sit in the middle of an automated payroll or accounts-payable process. If your ERP, payroll platform, or accounting system already has recipient, account, and amount data, it can send those records directly to the NACHA generation API and receive a ready-to-save fixed-width ACH file.

The NACHA generation endpoint

Send a JSON POST request to /api/v1/nacha/generate. The endpoint requires an x-api-key header from a user-scoped API key. Authentication details belong in the API documentation; the important NACHA-specific requirement is that the key's account has its Company Settings configured first.

Send payment rows as JSON

Each transaction needs a receiving routing number, receiving account number, amount, and recipient name. The following request uses the documented field names directly, so no column mapping is needed:

POST /api/v1/nacha/generate
x-api-key: YOUR_USER_SCOPED_API_KEY
Content-Type: application/json

{
  "bankType": "NACHA_PPD",
  "companyName": "Acme Payroll LLC",
  "nachaCompanyEntryDescription": "AUG PAYROLL",
  "nachaEffectiveEntryDate": "2026-08-27",
  "nachaTransactionType": "credit",
  "nachaAccountType": "checking",
  "transactions": [
    {
      "receivingRoutingNumber": "021000021",
      "receivingAccountNumber": "1234567890",
      "amount": 1500.00,
      "creditorName": "Jordan Lee",
      "individualId": "EMP001",
      "remittanceInfo": "August salary"
    }
  ]
}

individualId and remittanceInfo are optional per-transaction fields. nachaCompanyEntryDescription, nachaEffectiveEntryDate, nachaTransactionType, and nachaAccountType are optional generation-time settings for the request.

Choose PPD or CCD explicitly

bankType selects the supported SEC code: use NACHA_PPD for consumer/payroll flows or NACHA_CCD for corporate/vendor flows. Any other value is rejected with 400. For the decision behind that choice, see PPD vs CCD: Which NACHA SEC Code Should You Use?.

The success response is the file, not JSON

A successful request returns HTTP 200 with Content-Type: text/plain. Its body is the raw fixed-width NACHA file itself: there is no JSON wrapper and no temporary download URL. Your integration should write that response body to the file location or bank-submission handoff used by your workflow, then apply your normal controlled delivery process.

Handle validation errors before a bank does

Invalid transaction data returns HTTP 400 with a row-specific error response:

{
  "status": "error",
  "errors": [
    "Row 2: receivingRoutingNumber: Routing number failed the ABA check-digit test (expected last digit 1)"
  ]
}

Surface those errors in the originating payroll or accounting workflow rather than retrying unchanged data. The checks follow the same routing and account rules covered in ABA Routing Number Validation; for the broader prevention checklist, see 10 Common NACHA File Rejections.

Example: a scheduled payroll handoff

1. A scheduled payroll job reads the approved employee payment rows from the payroll system.
2. It selects NACHA_PPD, creates the transaction array, and calls /api/v1/nacha/generate with its user-scoped API key.
3. If the response is 200 text/plain, the job stores the returned NACHA text in its controlled submission location for the bank workflow.
4. If the response is 400, the job records the row-level errors for correction and does not treat the payroll run as generated.

This separates payment-data preparation from fixed-width file construction: your system owns the source data and approval process, while the API produces the NACHA record layout only after the required validation and Company Settings checks pass.