The syntax required to use the API will be instantly accessible to new developers. Many programming languages provide semantic guidelines for APIs as well. So knowing the language an API is programmed in gives you a huge advantage in beginning to understand it.

With a DSL, all that goes out the window. The syntax of the language is potentially unknown to you. The semantics are an even deeper mystery. You're in terra incognito, trying to understand the mental process of the developer of the DSL before you can even understand what the code written in the DSL intends to do.

The primary goal of programming languages is not to describe how to perform a complex task to a computer. It is to describe how to perform a complex task to other humans in a form that computer can also execute.

I'm not sure I buy the whole syntax argument. I programmed in Forth for a while and it seemed like it was much easier to build up an understandable vocabulary than some of the C++ / Smalltalk class hierarchies I have seen. REBOL has dialects that work fairly well. I cannot help but think that DSLs are refinement of APIs the same way C is a refinement of Assembler.

When I talk to someone about what happens in a system it seems like a DSL flows from that conversation.

"It is to describe how to perform a complex task to other humans in a form that computer can also execute."

I think a DSL does that much better than a set of API calls, particularly when you involve non-developers. That is the point of a DSL.

I see APIs as a less extreme version of DSLs (in that they share a common language, while building a DSL frees you from almost any restriction), but I honestly don't have enough experience building APIs or DSLs to give you a satisfying answer. Sorry.