Thanks!  It turned out it was the CheckLanguage property. Finally manage to create a customer via the web api. It would be nice if the messages always stated which property is the problem instead of having to guess. I hope I don't have to go through this pain when Sage 300 is updated again.

Your method sounds like a trial-n-error approach.  However, might be faster than my current process of redeploying app after every test.  I'll try it. Thanks for sharing.

Gary

Hi Gary, that's awesome news, really happy to hear that!  Unfortunately my method is definitely trial and error because I don't come across enough of the same import type to retain the knowledge, especially as what works for one site often won't work for another .  It would be a dream to have 10 new clients in a row with almost identical businesses and business processes.   Depending on how your Customer groups and A/R Options are configured, one site will have required fields and values that another won't.  As much as I try to save time, I always end up reverting back to doing an export, trim fields, and import test.  Not very efficient I know.  As the API matures and more people use it, its likely Sage will catch more exceptions and give them friendlier messages.  I haven't looked how active the Github is but the dev's might visit regularly.  One good thing I can say to your comment on updates is that Sage are generally very good at maintaining backwards compatibility with their APIs and import fields - they might add new fields and capabilities but rarely do I have an import break after a version change

Hi Gary, that's awesome news, really happy to hear that!  Unfortunately my method is definitely trial and error because I don't come across enough of the same import type to retain the knowledge, especially as what works for one site often won't work for another .  It would be a dream to have 10 new clients in a row with almost identical businesses and business processes.   Depending on how your Customer groups and A/R Options are configured, one site will have required fields and values that another won't.  As much as I try to save time, I always end up reverting back to doing an export, trim fields, and import test.  Not very efficient I know.  As the API matures and more people use it, its likely Sage will catch more exceptions and give them friendlier messages.  I haven't looked how active the Github is but the dev's might visit regularly.  One good thing I can say to your comment on updates is that Sage are generally very good at maintaining backwards compatibility with their APIs and import fields - they might add new fields and capabilities but rarely do I have an import break after a version change