You are touching upon the difference between an External DSL (a separate language with its own syntax and semantics) and an Internal DSL (a way to creatively design an API in such a way that using it feels like a different language, even though it is actually still bound by the syntax and semantics of the "host" language).
You will also sometimes hear the term Embedded DSL for the latter (and more confusingly see it abbreviated as EDSL) and just DSL for the former. This is basically a cultural difference, e.g. the Ruby community uses the Internal DSL / External DSL terminology, whereas the Haskell community uses the EDSL / DSL terminology. However, I find the term Embedded DSL ambiguous, because it sounds more like a language embedded in a different language, e.g. like regexps are "embedded" into Perl or LINQ is embedded into C♯.
As to your question where the border is … I believe there isn't one. Every language is an API, and every API is a language. The "better" an API is, the more "language-y" it feels. API design is language design.
This is especially true for OO: if you go back to Alan Kay's vision of OO, it is highly inspired by what would later become the ARPAnet and then the Internet. Computers (objects) which are separated (encapsulated) from each other and have their own private memory (instance variables) communicate with each other by sending messages (calling virtual methods). In fact, he even used the term "messaging" for what we nowadays call "virtual method call", and the API of an object is still called its "protocol", usually informally, but in Objective-C for example even as a language feature.
So, the networking metaphor and terminology is deeply ingrained in OO thinking. In very early implementations of Smalltalk, there weren't even methods (or objects). There were message streams flowing through the system, and these streams were parsed, interpreted, re-written and re-routed. Then, a couple of patterns emerged: 1) there would be clusters of closely related "stuff" in the "sea of messages", these later became "objects", and 2) there was a peculiar pattern where the beginning of a message denoted some enumerated set of actions, and the rest of the message parameterized that action, these later became "methods" and "messages".
Note, how I talked about parsing and interpreting messages above? Doesn't that sound like a language implementation? We can indeed interpret each object in an OO system as an interpreter for its own language!
Note, however, that your API really doesn't feel very "language-y" at all. While I said that every API is a language (and vice-versa), there's still the question as to whether it will commonly be recognized as such. If you think about Rake, Gemspecs, RSpec, or the Rails Routing API in Ruby, for example, when people look at them, they'll intuitively see a language, and only later realize that it's actually "just Ruby code". OTOH, when I look at your code, I see C♯, not something different, so it just doesn't "feel" like a language.
- what your colleague means is an Internal DSL, what you mean is an External DSL
- there is no clear border between API and language, good APIs are designed like languages
- languages are deeply ingrained in the fabric of OO, objects are essentially interpreters