Server 400 reponse when updating date property with API call



I have a custom property “QuoteDate” on my deals properties that I made in late December. I have been making the same calls consistently in Java App for other identically defined date picker fields (albeit with different names!) for a few months with no dramas

I know that the definition required is milliseconds since 1970 etc.

However I have run into a couple of snags in the new year - it seems if I now when I submit my JSON to the site using a PUT call to:

I get a server response of 400 for newly created deal properties.

I have been looking into this today and have established if I change the definition of the property to a single line string through the front end then all is well with the API PUT and it dumps in the desired value as text, “1513583567000”, say

After I have run through a debug of the java code in Eclipse; if I change the field definition back to “date picker” then the date picker is correctly populated, “18/12/2017” for the above example [[millis since 1970]]

Has anyone else seen this before?

This is the obfuscated PUT parameters I used for both the successful 200 when the field was a string and the unsuccessful 400 when it was defined as a date

{ “associations”: { “associatedVids”: [ 606802 ] }, “properties”: [ { “timestamp”: “1513583567000”, “value”: “XXXXX”, “name”: “dealname” }, { “timestamp”: “1513583567000”, “value”: “013f918a-0d2f-42e9-bf54-fd61af2b6072”, “name”: “dealstage” }, { “value”: “281bc03c-a051-4695-8e00-08294774dcb6”, “name”: “pipeline” } , { “timestamp”: “1513583567000”, “value”: “10.0”, “name”: “amount” }, { “value”: “newbusiness”, “name”: “dealtype” }, { “value”: “XXXXXX”, “name”: “quote_number” } , { “value”: “null”, “name”: “policy_number” }, { “value”: “XXXX”, “name”: “indication_number” } , { “value”: “10.0”, “name”: “indication_amount” }, { “value”: “”, “name”: “broker_sub_cluster” }, { “value”: “”, “name”: “broker_state” }, { “value”: “”, “name”: “broker_region” }, { “value”: “Test”, “name”: “broker_company” }, { “value”: "", “name”: “email” }, { “value”: “”, “name”: “broker_cluster” } , { “value”: “”, “name”: “broker_category” }, { “value”: “PI IT - Designers”, “name”: “sub_product” }, { “value”: “XXXX…”, “name”: “insured_name” }, { “value”: “PI IT”, “name”: “product” }, { “value”: “RENEWAL - Professional Indemnit…”, “name”: “product_description” }, { “value”: “Open Market”, “name”: “scheme_type” },{ “value”: “Currently insured elsewhere”, “name”: “indication_type” },{ “value”: “null”, “name”: “policy_status” },{ “value”: “”, “name”: “previous_policy_number” },{ “value”: “”, “name”: “pl_policy_number” } ,{ “value”: “”, “name”: “er_policy_number” },{ “value”: “0.0”, “name”: “pl_minlimitoptioninquote” } ,{ “value”: “0.0”, “name”: “erisks_policyusedbasepremium” },{ “value”: “0”, “name”: “offerings” },{ “value”: “Commercial”, “name”: “indicationuwteamname” },{“value”: “1513583567000”,“name”: “quotedate”},{ “value”: “Test”, “name”: “brokerid” },{ “value”: “Designers”, “name”: “industry” }]}




Can you send me a link to the deal property in HubSpot so that I can do some testing? Also, are you updating existing deal records or creating new ones?


Thanks for the reply Derek

This is on update of existing deals records using PUT to a known dealid – the property is

Thanks for your help



Chris Morgan

IS Team Lead



So a couple things to consider here:

  1. The quotedate property is a date property, not a datetime property, so it will only accept unix timestamps set to UTC midnight for a particular day. This isn’t necessarily the issue, just something I wanted to mention upfront. I’ve included some documentation on the distinction below.
  2. The endpoint to update an existing deal is, and it accepts PUT requests. Calls to /deals/v1/deals have to be POST requests, and will create new deals.

Can you try to make another request to the update deal endpoint with a timestamp set to UTC midnight?


Hi Derek

Sorted this by updating the type to datetime using the deal properties api for properties that I may need the time recorded for in the future

Thanks Derek, much appreciated!



Chris Morgan

IS Team Lead