API defines an abstraction - I assume you're askng about understanding that abstraction completely, not the specifics of how it is implemented. An abstraction can include changes of (abstract) state, and it can include performance characteristics/gotchas (as in Joel's "Leaky Abstractions").
An API can be designed for learning, by forming a series of nested abstractions, such that you can completely understand each well-defined subset independent of understanding all the other subsets. Perhaps an example is a String object in Java or Python. Understanding creation and assignment is a completely self-contained subset of its functionality, without using any of its methods (as such). A deeper level of understanding includes performance characteristics.
To answer the question: I feel I must understand the subset of the abstraction that I am using, in order be confident in the correctness of my code.
But many APIs are not designed this way. Designing APIs for usability is hard, and most programmers prioritize features, performance and internal elegance over it. I suffered to write this. Now it's your turn.
And, worse, the implementations of many APIs have bugs (well, all of them do). It's just that more users find more bugs, so more popular libraries usually have fewer bugs (in their mature parts).
I find a constant pressure between writing the best possible code - and getting things done (one advantage of getting something done is it puts you at a vantage point where you can see more - and becoming part of the process of understanding).
For me, the answer is "not always". When the topic is security or performance, I definitely prefer to have as much knowledge of the API as possible.
I remember reading an interesting article about Java's File and how the internal implementation used null terminated strings (which ultimately meant that you could bypass a string-based check (such as 'filename.endsWith(".jpg")' and have the subsequent new File(filename) call open a different file than you'd expect.
On a different story, I was able to speed-up a web-app speed significantly because I knew (from reading the js library's source code) that the DOM querying functions we were using so extensively were very inefficient.
With those anedoctes out of the way, I'll say that knowing how every single function in every single API ticks is probably overkill. I usually only dig deeper when
a) I have to because something needs to be fixed b) It's a very specific area of expertise that happens to interest me
So I think it's part of the difference between being a journeyman and an expert. That said, not all APIs are worth understanding, and you don't need to go into exhaustive detail with everything; it's a question of deciding what's worth learning in the long-run.