Open marczahn opened 6 years ago
@marczahn I'm not sure why I added this, it was a while ago. If close.io is happy with it then I'd say it's fine to remove. I think if we can catch errors before sending the request to close.io it could be more efficient than waiting for the response, but I guess either is fine.
It is even stranger since organization is not used at all :-)
I'll leave it with you @marczahn. As long as the tests pass and you've tested it with real close.io requests then it should be fine. It would be very nice if we had a test close.io instance we could run real API requests against, just to ensure our wrapper is compatible with their changes.
I'll approve this anyway and if anything goes wrong then we all know who broke it :stuck_out_tongue:
@mickadoo I just remembered why this was: The lead requests and responses are slightly different and some fields may not be sent.
@mickadoo Is there a reason for excluding exactly this field? And would it make sense to remove validateLeadForPost completely and to rely on errors sent from closeio?