Python API 2.1 - urllib2.HTTPError: HTTP Error 400: Bad Request

Hello,

Create contacts requests that worked before started failing.

Payload:
{'ADDRESSES': [{u'ADDRESS_ID': 0,
u'ADDRESS_TYPE': u'None',
u'CITY': '',
u'COUNTRY': 'Australia',
u'POSTCODE': '2000',
u'STATE': 'NSW',
u'STREET': 'Level 10, 20 Martin Place'}],
'CONTACTINFOS': [{u'DETAIL': 'Jack.Smith@zxc.com', u'TYPE': 'EMAIL'}],
'CONTACT_ID': 0,
'FIRST_NAME': 'Jack',
'LAST_NAME': 'Smith',
'LINKS': [{u'ORGANISATION_ID': u'103725000', u'ROLE': 'Director'}],
'ROLE': 'Director'}

Creating a lead still works fine:
success = ins.create('leads', c)
Creating a contact fails with 400 bad request:
success = ins.create('contacts', c)

Please tell me how this can be fixes as soon as possible.

Thanks

0

Comments

19 comments
  • Hello Dima,

    We updated Contact and Organization entities over the weekend to simplify our data structure. Looking at your payload, ADDRESS_TYPE of 'None' isn't supported. Please refer to v2.1 documentation (scroll to the bottom to see supported ADDRESS_TYPE values) for more details.

     

    Thanks!

    0
    Comment actions Permalink
  • Changing older API and breaking integrations is fantastic! However, clearly ADDRESS_TYPE isn't the only thing that changed because I still get the same error. Ideas? 


    {'ADDRESSES': [{u'ADDRESS_ID': 0,
    u'CITY': 'dddd',
    u'COUNTRY': 'aaaa',
    u'POSTCODE': '324',
    u'STATE': '',
    u'STREET': ''}],
    'CONTACTINFOS': [{u'DETAIL': 'at@foo.au', u'TYPE': 'EMAIL'}],
    'CONTACT_ID': 0,
    'FIRST_NAME': 'Mark',
    'LAST_NAME': 'Zaa',
    'LINKS': [{u'ORGANISATION_ID': 103779150, u'ROLE': 'Works'}],
    'TAGS': [{u'TAG_NAME': 'Government'}]}

    0
    Comment actions Permalink
  • Hello Dima,

    ADDRESS_TYPE is a required field. It must be one of the following values: 'Postal', 'Work', 'Primary', 'Home' or 'Other'. 'Postal', 'Work' and 'Primary' map to the Mailing Address and 'Home' and 'Other' map to the Other Address.

    Hope this helps!

    0
    Comment actions Permalink
  • Hello Sushamna,

    It does help, but your API update sure is a gift that keeps on giving. Frankly, I'm outraged about changes that break compatibility, and add features I don't care about to an older version of an API. I don't know who told your developers that this is acceptable. I think that you urgently need to hire an experienced product manager. 

    There is another good example of why your update is useless and annoying:
    Country field is now matched against a list. In principle, it might've been a good idea, if someone thought more carefully about the implementation.
    1) Korea isn't on the list, Lao is actually called Laos. This needs to be fixed asap, as I can't import contacts.
    2) If you add a feature like that, you need to do it through a country name look up. You get the name and convert it to an iso3c representation and then back to a string representation. Because this feature is poorly implemented, it creates a lot of problems on my end. Now, I need to implement conversion like the one I've described on my end. And so does anyone working with a large number of contacts spread all over the world. Wouldn't you agree that this should've been handled on your end?!

    Cheers,
    Dima

    1
    Comment actions Permalink
  • I can also see that CONTACTINFOS is now limited to one email address, which makes no sense whatsoever. What possible rationale did your team use when adding this "functionality"?!

    0
    Comment actions Permalink
  • Hi Dima,

    While the recent changes only allow you to have one primary email address per contact, with the tool that was just released you can add your extra emails into custom fields with a click of a button.

    Insightly will also number the new custom field labels for you. For example, if you have a contact with 3 extra work email addresses, your custom fields will be Email Work 1, Email Work 2, and Email Work 3. You can learn more about it here.

    0
    Comment actions Permalink
  • Hi Nora,

    How are you going with adding North and South Korea to the list of countries, as well as renaming Lao to Laos?

    Also, can I expect you team to keep introducing additional changes to a v2.1 of the API?

    Cheers 

    0
    Comment actions Permalink
  • Hi Dima:

    Your request for those countries has been noted but there isn't a plan for having those added.

    With regard to the API, v2.2 is actively supported. If you see something strange in v2.1 we'd be happy to look into it.

    0
    Comment actions Permalink
  • Well Lyla, those countries exist, and we have contacts in all 3 of them. Seeing as you don't plan on adding them, what do you propose we do?

    2 weeks ago you made significant changes to v2.1. My questions was, do you plan on introducing additional changes to v2.1? Such changes break compatibility, and hence introduce work.

    0
    Comment actions Permalink
  • Hello Dima,

    You'll notice that North Korea and South Korea are already available in the list of countries, and we are looking into renaming Lao to Laos. Thanks for bringing that to our attention!

    Regarding v2.1, we do not have plans to make any functionality changes.

     

    Thanks!

    0
    Comment actions Permalink
  • Thanks Sushamna!

    0
    Comment actions Permalink
  • This is NOT the way API changes should be made! Very unprofessional - and additionally there is no 2.1 api changelog even in some basic form on https://api.insight.ly/v2.1/ page.

    What should I do now? Get original docs page from some kind of cache and compare to find changes? Read everything in hope to find whats changed? Ridiculous

    0
    Comment actions Permalink
  • This was an update to an older version of the API rolled out over the weekend without a warning.

    This is how I learned about county validation, which I then had to debug for them, and which still remains completely backwards as a feature implementation, since entity resolution should happen on the CRM end. It takes 10 minutes to write 3 lines of code that match country names to an iso3c code. Please hire someone who understands technology and development life-cycle.

    0
    Comment actions Permalink
  • Additional questions: Why "Website" was removed from 'Contactinfos' and where it can be added now?

    It makes no sense, this is pretty commonly used field and should be visible right away when viewing contact informations , not hidden under Notes (url not clickable) like it is done now after your automatic conversion.

    0
    Comment actions Permalink
  • I'm also getting similar 400: Bad Request errors for PUT requests. Even after poring through your documentation, using a GET call to compare with an existing organization, and sending my PUT request multiple times with slight variations, I still get the 400 error.

    I don't know why this payload fails:

    {
        'ADDRESSES': [{
            'ADDRESS_TYPE': 'Work',
            'CITY': 'Somewhere',
            'COUNTRY': 'United States',
            'POSTCODE': '11111'
            'STATE': 'AA',
            'STREET': '1 Somewhere St',
        }],
        'BACKGROUND': 'Blah',
        'CONTACTINFOS': [{
            'TYPE': 'Phone',
            'LABEL': 'Work',
            'DETAIL': '(999) 999-9999',
            'SUBTYPE': 'Some Dude'
        }],
        'CUSTOMFIELDS': [{
            'CUSTOM_FIELD_ID': 'ORGANISATION_FIELD_1',
            'FIELD_VALUE': 'Some Dude'
        }, {
            'CUSTOM_FIELD_ID': 'ORGANISATION_FIELD_2',
            'FIELD_VALUE': 'AA-AAAA'
        }, {
            'CUSTOM_FIELD_ID': 'ORGANISATION_FIELD_3',
            'FIELD_VALUE': 'Some Stuff'
        }, {
            'CUSTOM_FIELD_ID': 'ORGANISATION_FIELD_4',
            'FIELD_VALUE': 'Some Dude'
        }, {
            'CUSTOM_FIELD_ID': 'ORGANISATION_FIELD_5',
            'FIELD_VALUE': 'Account Manager'
        }, {
            'CUSTOM_FIELD_ID': 'ORGANISATION_FIELD_6',
            'FIELD_VALUE': datetime.date(2016, 1, 19)    # also tried "2016-1-19"
        }],
        'ORGANISATION_ID': '11111111',    # also tried the id unumber without quotes
        'ORGANISATION_NAME': "111 Organization",
        'VISIBLE_TO': 'Individuals',
        'VISIBLE_USER_IDS': '555555'
    }

     

    Is it really too much to ask for these API calls to return an actual error report?

    0
    Comment actions Permalink
  • Hi Abram,

    It seems that you have missing a comma after the 'POSTCODE': '11111' area.  After adding the comma, I was able to create/update the organisation.  I hope this helps.

     

    Regards,

    Kevin

     

    0
    Comment actions Permalink
  • Hi Engineering,

    Thanks for the response. However, I still get a "400 Bad Request" error for this type of request with the comma in place, which I tested yesterday.

    Guess and test is really the worst debugging method I can think of. Your API already returns a nice amount of data for successful update requests. How about doing the same for errors and providing a proper error report?

    0
    Comment actions Permalink
  • Hi Abram,

    The reason why the update failed is because CONTACT_INFO_ID is not provided.  Since I am not familiar with python, I can't show you why you don't see the error message from response body.  I tested your dataset again with Postman (REST Client), here is what I see.  

    Response Body: "The Contact Info already exists. Please specify a valid CONTACT_INFO_ID to update the existing record."

     



     

    0
    Comment actions Permalink
  • Aha, now that is useful information. I will see if I can get access to the Response body using the Python API. Thanks!

    0
    Comment actions Permalink

Please sign in to leave a comment.