What since entities !== what we get via the API and what get saved in the DB, what layers should perform that transformation?
Parsing the request, by which I mean taking the representation of the information you get from your general purpose HTTP library/framework and converting it to an in memory representation of the API message, is normally an activity that you want to happen as close to the boundary as practical. So the parser might be invoked by the controller itself, or close to it (if you have multiple HTTP frameworks supporting the same API).
(See Parse, Don't Validate by Alexis King).
The function that you use to convert from the in memory API representation to your domain representation is going to have dependencies on your API definition and domain model definition, so you're probably looking at "application layer" there (based on the dependency arrows; of course there are some cases where the API definition and the domain model definition are in close alignment, so it may be tempting to blur the two -- but keep in mind that API and domain model change for different reasons).
There's a similar argument for the case where you are taking domain values and converting them into your API representation.
For information coming from your persistence store, the basic idea is roughly the same - the primary difference being that your data store is supposed to be under your own control.
The application code will normally access the data via a "repository", which is going to depend on some flavor of "infrastructure code" that knows how to fetch the data that you need, and a domain factory that knows how to take general purpose data into the data structures that you need.
Similarly, you're going to need code that can extract information from your domain model (the entities) and transform that information into the general purpose representations that are understood by the infrastructure component talking to your data store.
A way of thinking of this latter transformation is that you've got some long lived schema (in the sense that we expect it to support many generations of domain model) that describes your data at rest, and you need a function that takes information out of the domain entity and expresses it in this storage form.
So either your domain entity needs to have methods to extract the information in this data representation, OR the entity needs to expose its internal information in a way that supports creating this data representation from the outside.
(In practice, what you'll often see is either (a) an O/RM implementation of the domain entity or (b) some flavor of implicit conversion to a general purpose representation of the information; think JSON mapping.)
Which is a long winded way of saying that we expect the repository to be able to invoke methods for serialization/deserialization of the domain model.
There may be some shock and outrage that the domain model might have dependencies on anything else, but as far as I can tell that doesn't work very well unless you never take information out of the domain model (in which case, what's the point?). In practice, our domain values often include dependencies on general purpose data structures (strings? collections?); the important constraint is to make sure that the dependency arrows point at things that are stable.
Expressed another way - if you are changing your data schema with every release, "onion architecture" is not going to protect you from having a bad time.