[jrochkind1]

A standardized data format with some standardized transport protocols... how is that _not_ an API?

I don't think whether the integrations need customization or not is relevant. Certainly many API's are "bespoke" and need custom integrations. But if it's designed to be standardized (whether it succeeds or fails, and many standards end up not being so standard), that certainly doesn't somehow disqualify it from being an API either.

It might be a difficult or easy API to work with; or how difficult or easy it is may depend on your context and platform.

[danielmarkbruce]

It's just the data format. There is no EDI transport protocol. JSON, XML, PDF etc, they aren't APIs. Neither is EDI. You can email a JSON file, you can sent it over http, you can FTP it, you can transport it a lot of ways. JSON isn't an API. EDI is the same(but way more detailed...).

[donzog]

There isn't a JSON transport protocol either. And EDI is not a format; it's a general reference for multiple data standards and the rules for exchanging data instances of them. One of the issues is that people have different opinions of what EDI is, which is confusing, pretty much as what their views about API are. Although the definition of EDI and API is expected to be "standardized", everyone seems to have their own flavor of it :) Pun intended.

[danielmarkbruce]

Which is why people use email, ftp, http and more to send JSON.

EDI is much more concrete than API. EDI has version/standards issues, but it's a pretty concrete thing and the different versions/standards are highly specified. API is vague, but generally there is a requirement that the API does something or represents something that does something. EDI doesn't really meet any definition of API...it doesn't do anything.

[donzog]

The different EDI standards are pretty explicit about the sequence of messages (276/277, etc.), acknowledgments (technical, functional, etc.), and conversation items (interchange IDs, duplicates, sender/receiver IDs, etc.). And yes, there is a requirement that EDI transactions do something or represent something that does something, in a specific way.

EDI does a lot of things, but its transport and semantics are visibly decoupled, whereas in web APIs, they appear to be somewhat uniform.

Web API is far from vague; on the contrary, it might even be more stringent (and selective) as the inbound data goes via multiple stages of validation as opposed to EDI, which does "take-all" data, then either "parse all" or "reject-all".

[danielmarkbruce]

"Web API"