Version 2.2 of the Insightly API live and available

We are pleased to announce that version 2.2 of the Insightly web API is officially live, and can be accessed at api.insight.ly/v2.2/Help. Read more on Working with the Insighty Web API.

The new API includes significant improvements in performance, ease of use and documentation, so we encourage customers to check it out. Among the improvements:

Improved performance, especially when accessing large recordsets, including support for pagination

We now support incremental changes to existing objects. For example, you can easily add an address to a contact by posting to /contacts/{id}/addresses. This enables you to make changes to an existing object without having to upload the entire object graph.

OData is replaced with a simpler set of optional query parameters. For example, to search contacts by email, just GET /contacts/search?email=foo@bar.com

Support for new custom field types.

And more, go the API site for full details and documentation. We will also be updating client side libraries to support v2.2 in the near future (the Python SDK will be updated first with more to follow).

Thanks for using Insightly.

Brian McConnell

Insightly Engineering Team

6

Comments

34 comments
  • Hi Stuart,

    For responsibleUserId, you should be able to assign an userId when create or update the record.

    For ownerUserId, it is automatically set to the API guid of the user account.

    If you have specific sample data that you couldn't get it to work, please contact us via support ticket along with the json blob, and we will validate it for you.

     

    Regards,

    Kevin

    0
    Comment actions Permalink
  • Hello,

    I am new to JSON based APIs and recently used the Swagger Codegen utility along with Insightly v2.2 API spec using the following command-line:

    java -jar swagger-codegen-cli-2.2.3.jar generate -i "Insightly API v2.2.json" -l java --model-package com.insightly.model --api-package com.insightly --invoker-package com.insightly.api --group-id com.insightly --artifact-id insightly-java-api --artifact-version 0.1.0-SNAPSHOT --additional-properties serializableModel=true,withXml=true,java8=true,dateLibrary=java8,useGzipFeature=true,artifactUrl="http://www.insightly.com",artifactDescription="Insightly CRM Java API" --library resttemplate -o "C:\git\insightly-java-api"

    A couple of observations:

    The model folder contains identical classes for the same domain entity. Do we need both of these?

    For example: APIOrganisation and Organisation are exactly identical except for their names.

    The actual EntityApi class seems to be using both the above mentioned classes.

    For example: The method public Organisation updateOrganisation(APIOrganisation apiOrganisation, Boolean brief) uses one as the method argument while the other as a return type!

    Duplicate local variables produced in the generated API produces code that does not compile out of the box.

    For example: The method OrganisationsApi.addFileAttachment(Long id, String file, String fileName, String contentType, Integer fileCategoryId) contains another local variable final MediaType contentType = apiClient.selectHeaderContentType(contentTypes);

    The Insightly API supports both GZIP and DEFLATE compression to reduce the payload size of data sent back to the client.

    The above listed Swagger Codegen command-line does not seem to generate the GZip/Deflate compatible code.

     

    The ultimate goal is to annotate the Insightly model classes such as Organisation, Address, ContactInfo, CustomField, etc as JPA entities to read/persist from/to a database for an efficient and robust integration with my application.

    Any guidance would be greatly appreciated.

    Thank you.

    -Sandeep Khanna

    1
    Comment actions Permalink
  • Hi all

    My developers have been working on a ruby gem for the v2.2 API and it is really close to being ready to publish.

    My guess is that as an entirely new codebase there is no point in trying to link it with the existing git gem.

    Any opinions on this?

    0
    Comment actions Permalink
  • Hi Feargal, 

    Glad to hear that your team  has a Ruby Gem for V2.2 of our API.  As you mention, V2.2  of our API that it is an entirely new code base, so it makes sense to have a separate Repo. Let me DM you on the next steps to make your Gem available. 

    Raju

    0
    Comment actions Permalink

Please sign in to leave a comment.