Your API documentation (or specification if you have one) is not your specification. Your API implementation is your specification, especially if you are the only provider of the API. I realize how trite that sounds, but it's true. Defensive API design (make it REALLY HARD to have undocumented tricks that developers can use in productive ways) is dramatically harder than API design is in the first place, and I still guarantee you'll screw it up for any moderately expressive API.
It's not just an issue of parameter validation or well-defined calls; it's the interactions between calls where this is hard. It's issues of ordering, timing, when you can secretly skip synchronization because you know the API will synchronize just enough for you to get away without something more heavyweight, things like that. And then when you have paying customers? Yeah, you can't break their code, even if it's bad, because if you do you won't have customers for very long.
It's not just an issue of parameter validation or well-defined calls; it's the interactions between calls where this is hard. It's issues of ordering, timing, when you can secretly skip synchronization because you know the API will synchronize just enough for you to get away without something more heavyweight, things like that. And then when you have paying customers? Yeah, you can't break their code, even if it's bad, because if you do you won't have customers for very long.