Off the top off my head, I would say use reflection, but it's not clear to me how you determine whether a field is an ID field or not. Or if a set of fields comprise a composite key and is so effectively is also an ID.
If would suggest that having to list each field (albeit tedious and error prone), is not really an issue. The reason I say this is because you would have to know all the fields anyway to create the second database.
Are you saying that it won't be tedious and error prone to clone the initial schema, and that is a perfectly okay problem to have, but it's not okay to have that same problem in the code?
Or did you just throw the schema problem over the wall to your DBAs (or whomever owns the second database and the web API)? And so now you are left with having to same problem that you just threw over the wall and are asking here.
I would suggest that whatever automation/scripting is used to solve the schema problem be also dual purposed to solve the problem of listing the fields that need to be copied. At best, you'll be writing some T4 templates that takes the database schema and generates helper classes. (search for "T4 text template transformation toolkit". It's built right into Visual Studio, as well as available at runtime.)
Another approach would be to look into AutoMapper. It excels in doing that kind of tedious field mappings. I would not be surprised if also supports "do not copy" field mapping rules.