Hi Ton,
I might be tempted to argue that your API design needs work.
In other words, if User Type A needs a method, then give them a method. If user type B needs a method (on the same table, but with "different clients own different part of the record structure" then perhaps that is a separate method.
Just trying to _document_ what goes where sounds like a nightmare to me.
That said;
I've thought a bit about your suggestion, but it gets very bogged down with lists. Nothing especially elegant is popping out at me. I've come up with a few suggestions in my head, but ultimately they all get very messy. And ultimately it comes back to the API design.
My biggest concern is not the omitted or null fields - that's probably solvable with priming of the fields with known "default" values. Rather my big concern would be security - ie what to do if the user sends you fields which they _shouldn't_ be sending. That's the key problem to solve first.
And that's where your choice of structure gets important. Using the table as the root structure, and trying to manage "who can write what fields there" is going to get ugly. So I'm back to where I started - perhaps it's best to create multiple API Methods, and in each use a Queue for the incoming list. Then manually move that queue into the table, taking security into account. This will likely solve the omitted issue as well because you could prime the queue records with "dud" values first - for example the name field might be primed to AAAAAAA so you can then see that primed field, and ignore it, when updating the table.
Cheers
Bruce