API Versions

Breaking changes log

Breaking changes represent any change in the API that potentially require attention if you are currently integrated with a specific version and want to use another. If this is your case, you need to be aware of those changes and adapt your integration accordindly.

v2

1) Changes in featuresCustoms and featuresProperties json format

Impacted services

• CertificationsSearch
• CertificationsCreate
• CertificationsUpdate
• DeclarationsSearch
• DeclarationsCreate
• DeclarationsUpdate
• MaterialsSearch
• MaterialsCreate
• MaterialsUpdate

Details

v1 format

"featuresCustoms":[
   {
      "name":"Supported temperature",
      "value":"1500C"
   }
],
"featuresProperties":[
   {
      "code":"LENGTH",
      "value":"60",
      "unit":"CENTIMETER"
   },
   {
      "code":"AVAILABILITY",
      "value":"ASIA"
   }
]

v2 format

"featuresCustoms":[
   {
      "code":"CUSTOM_TEXT_ATTRIBUTE",
      "name":"Supported temperature",
      "value":{
         "content":"1550C"
      }
   }
],
"featuresProperties":[
   {
      "code":"LENGTH",
      "value":{
         "content":"60"
      },
      "unit":{
         "code":"CENTIMETER"
      }
   },
   {
      "code":"AVAILABILITY",
      "value":{
         "code":"ASIA"
      }
   }
]

2) idealProjects removal - now handled as featuresProperties

Impacted services

• MaterialsSearch
• MaterialsCreate
• MaterialsUpdate

Details

v1 way to specify ideals projects

"idealProjects":[
   {
      "value":"COMMERCIAL"
   },
   {
      "value":"RESIDENTIAL"
   }
]

v2 way to specify ideals projects

"featuresProperties":[
   {
      "code":"IDEALPROJECTS",
      "value":{
         "code":"COMMERCIAL"
      }
   },
   {
      "code":"IDEALPROJECTS",
      "value":{
         "code":"RESIDENTIAL"
      }
   }
]

3) PropertyDetailsLookup the response payload documentation not match with the actual payload - fixed in v20.11

Impacted services

• PropertyDetailsLookup

Details

This change doesn't break the message format, but if you tried to match your implementation with the documentaion, you should have seen that it didn't work.

The result.searchInfo has been removed from documentation.

The result.data[] and result.data[].* have been replaced by result.propertyResource and result.propertyResource.* in documentation.

The response samples has been replaced to reflect the previous changes.

v1

1) originUrl now return originId (uuid) instead of database id (numeric)

Impacted services

• MaterialsSearch

Details

This change doesn't break the message format, but if parsing logic has been developed on the originUrl value, there is a possibility of impact.

Prior to this change, originUrl return by the MaterialsSearch service contained a numeric id and looked like this :

"originUrl" : "https://origin.build/#/material/123456789?locale=en"

The new value return an originId uuid instead and look like this :

"originUrl" : "https://origin.build/#/material/93bcbf18-51fb-11e8-8716-8c16451835eb?locale=en"

2) PropertyDetailsLookup the response payload documentation not match with the actual payload - fixed in v20.11

Impacted services

• PropertyDetailsLookup

Details

This change doesn't break the message format, but if you tried to match your implementation with the documentaion, you should have seen that it didn't work.

The result.searchInfo has been removed from documentation.

The result.data[] and result.data[].* have been replaced by result.propertyResource and result.propertyResource.* in documentation.

The response samples has been replaced to reflect the previous changes.