[zkanter]

It's definitely possible to write simple EDI transactions (no HL loops, etc) with a couple of trading partners using something akin to mustache templates – many of our customers come to us after getting something basic like this up and running in a day or two, and then hitting complexity.

It's difficult to use the method you're describing to write a transaction like this, particularly when the receiver's system can fall over due to a single character out of place: https://www.verizon.com/business/support/vec/onlinehelp/dam/...

(I'm the CEO of Stedi)

[bena]

I had to process ANSI X12 835/837 sending and receiving.

So, you know, Healthcare billing information. It's tedious, but the worst part is the mapping from your own data source to the format. And you don't help with that part.

[zkanter]

Yep, there's no way around mapping – the data has to get mapped somehow. The 835/837 are a bear. You can save some time if someone has built a mapping template already – say, from a transaction type in Oracle to the 837 – but if it's a custom system you're mapping to/from (like a homegrown API), it's impossible for a template to exist...it has to be done from scratch.

We've found that many of the fields end up being single-item enums, so those can be hardcoded (i.e. no mapping required). Guides (https://www.stedi.com/products/guides) generates JSON Schema for you, and Mappings (https://www.stedi.com/products/mappings) automatically populates any single-item enum. Both are free to configure in the UI.