We recently upgraded from 4.9.4 to 4.17, and I've noticed a change in the Native API (which hasn't changed versions, as far as I can tell). It has to do with the View a Dataverse endpoint (http://guides.dataverse.org/en/latest/api/native-api.html#view-a-dataverse).
In the past, there was a 'creator' key that pointed to an array of metadata about the user who created the dataverse. But now with version 4.17 it only returns an 'ownerId' key with what I'm assuming is the internal id of a user. I'm not sure yet if this ownerId is pointing to the authenticateduser or the builtinuser table.
I know there is an API endpoint in the administrative part of the Native API to get the metadata about a user, but the endpoint requires their identifier, not ID. So the only way I can see to get around this is to hit the list-users API endpoint in the administrative part that returns all users and then iterate through them until I find matching ID's.
I just wrote the code to try this, and so far I'm finding enough ownerId's that aren't in the list-users endpoint to make me think that I don't have the solution yet. So I figured I would ask about the change to the API, in case I'm not understanding something.
@nwoodward hi! @CCMumma mentioned this a couple hours ago on the community call.
This change to the API was introduced in Dataverse 4.12 as part of pull request #5655.
The reasoning was that the UI doesn't show who the contacts for a dataverse and the API shouldn't either.
That said, you an revert to the old behavior by setting :ExcludeEmailFromExport to false.
Here's a screenshot of the docs from the version you're running: http://guides.dataverse.org/en/4.17/installation/config.html#excludeemailfromexport

In the code (from that pull request), here's the logic that was added:

But now with version 4.17 it only returns an 'ownerId' key with what I'm assuming is the internal id of a user. I'm not sure yet if this ownerId is pointing to the authenticateduser or the builtinuser table.
Also discussed in the community call (see call notes) but I thought I'd mention the answer here too, that owner_id here refers to the id of the parent dataverse
@jggautier thanks for adding that, because I had actually added that note after the call had ended
@pdurbin hey! That change makes total sense. @jggautier and thank you for the clarification. I was just writing out a comment to ask if I could use that field to find creator metadata. Since it's clear that I can't, we'll rethink how we conceive of users of a certain institution.
One idea could be to add the creator info back if you're a superuser. (and maybe only if you add a flag to the request, so that you know you're getting identity info.
I've got one question about the dataverseContacts nested array that appears when this field is set to false. Is there any ordering logic in the case where there are multiple contacts? For example, is the first person in the list the dataverse creator? Or is the ordering more general, like alphabetic or something like that? It would be good if I could determine the creator, but if not I may just list all contacts.
@nwoodward according to http://phoenix.dataverse.org/schemaspy/latest/tables/dataversecontact.html there is a display order so I think the order is significant:

In addition, it looks like an "add" is an "append", if that helps:

But as you point out, these are contacts, not the creator. There is only one creator (who may have switched jobs, who knows) but multiple contacts are possible. Any relationship between the creator and the first contact is the list is only implied, I'd say.
Thanks for the information! I think I have some more work to do to figure out what relationship a contact has with a dataverse, but it's probably fair to say I can't point to any one creator.
Hey @nwoodward, I'm going to close this issue out as I'm unsure of our next steps, but if you have more questions or if you have some additional info (or documentation recommendations) please feel free to let us know and we can reopen this.