{"status":"error","message":"Property values were not valid: [{\"isValid\":false,\"message\":\"1601856000000.0 was not a valid long.\",\"error\":\"INVALID_LONG\",\"name\":\"signup_date\"}]"}
When I change the HubSpot property to text type, it works fine. But I need it to remain as a date field. What am I doing wrong with the timestamp format?
That decimal point in your timestamp is what’s causing the INVALID_LONG error. HubSpot’s API wants pure integers for date fields, but your double is getting serialized with .0 at the end.
I hit this same issue last year during a customer data migration. It’s not just the data type - JSON.NET serializes doubles with decimal notation even when they’re whole numbers.
Besides switching to long like others mentioned, I’d add JsonConverter attributes to keep serialization clean. Some edge cases still produced weird formats even with correct data types.
Good catch on using UTC timestamps. Just double-check your source dates are parsing right - I’ve seen ToShortDateString() cause timezone shifts that only showed up later, not during testing.
HubSpot wants an integer timestamp, not a float. You’re getting 1601856000000.0 instead of 1601856000000.
Change your property type to long:
[JsonProperty(PropertyName = "signup_date")]
public long? signupDate { get; set; }
And fix your conversion method:
public static long ConvertToTimestamp(DateTime inputDate)
{
inputDate = DateTime.SpecifyKind(inputDate, DateTimeKind.Utc);
var timestamp = ((DateTimeOffset)inputDate).ToUnixTimeMilliseconds();
return timestamp;
}
This gives you clean integers like 1601856000000 without the decimal.
Honestly, these API quirks get old fast. I’ve been doing HubSpot integrations for years and found that automation platforms save tons of debugging time.
Latenode handles these conversions automatically and has built-in HubSpot connectors that just work. You can set up contact updates in minutes without dealing with timestamp formats or JSON serialization headaches.
You’re receiving a “Property values were not valid: [{"isValid":false,"message":"1601856000000.0 was not a valid long.","error":"INVALID_LONG","name":"signup_date"}]” error when trying to update a HubSpot contact’s “Date Picker” field using a C# application. Your application sends a timestamp as a double, which HubSpot’s API rejects because it expects a long integer.
Understanding the “Why” (The Root Cause):
HubSpot’s API for date picker fields expects Unix timestamps represented as long integers (whole numbers without decimal points). Your C# code, using double? signupDate, and the JSON serializer you are using, outputs the timestamp with a trailing “.0” (e.g., 1601856000000.0). Although mathematically equivalent to 1601856000000, the API’s validation treats this as a floating-point number, causing the INVALID_LONG error. This isn’t just a data type issue; how the double is serialized into JSON is the root of the problem. Even if you corrected the type to long, the serializer’s settings might force the .0 format.
Step-by-Step Guide:
Change the Data Type to long: Modify your C# code to use long instead of double? for the signupDate property:
[JsonProperty(PropertyName = "signup_date")]
public long? signupDate { get; set; }
Correct the Timestamp Conversion: Update your ConvertToTimestamp method to return a long:
public static long ConvertToTimestamp(DateTime inputDate)
{
inputDate = DateTime.SpecifyKind(inputDate, DateTimeKind.Utc);
return ((DateTimeOffset)inputDate).ToUnixTimeMilliseconds();
}
Explicit JSON Serialization Settings (Recommended): To prevent the JSON serializer from adding the “.0” suffix even with a long, explore the serializer settings of your chosen JSON library (e.g., Newtonsoft.Json). Many libraries allow for fine-grained control over how numeric types are serialized. This step ensures consistent integer output, regardless of other parts of your code or potential changes to the serializer configuration. The specific settings will vary depending on your JSON library; consult its documentation for details on disabling floating-point formatting for long integers.
Verify the Input Date: Double-check that your DateTime.Parse(userInfo.registrationDate.ToShortDateString()) call correctly handles time components and timezone conversions. If userInfo.registrationDate already has time components, using .ToShortDateString() might result in unexpected time zone changes leading to incorrect timestamps. Consider using the Date property directly instead, ensuring the resulting timestamp represents the date at midnight UTC. If milliseconds are critical, consider using DateTimeOffset.FromDateTime(inputDate).ToUnixTimeMilliseconds() as suggested in some of the original responses.
Common Pitfalls & What to Check Next:
JSON Serializer Configuration: Even after correcting the data type, explore the configuration options of your JSON library to ensure numbers are not formatted with unnecessary decimal places. This is often a global setting, so a misconfiguration in one part of your application might influence this property.
Caching: HubSpot’s API might cache responses, so you might continue to see the error even after fixing the code. Try clearing your application’s cache or waiting a short period to ensure you are receiving the latest results.
Other Date Fields: If you have multiple date fields, verify that they are all correctly configured and serialized as long integers.
Still running into issues? Share your (sanitized) config files, the exact command you ran, and any other relevant details. The community is here to help!
Had this exact error on a CRM sync project recently. The decimal notation’s definitely the problem, but your DateTime parsing might be creating precision issues too.
When you call DateTime.Parse(userInfo.registrationDate.ToShortDateString()), you’re converting to string and back to DateTime, which can mess with milliseconds. I just work directly with the original DateTime object and zero out the time component if I need to.
HubSpot also caches validation errors sometimes, so even after fixing the long conversion, you might see the same error for a few minutes. I wasted way too much time thinking my fix wasn’t working when it was just cached API responses.
Everyone’s right about the long conversion, but try DateTimeOffset.FromDateTime().ToUnixTimeMilliseconds() directly instead of the SpecifyKind approach. Fewer moving parts and less chance of timezone issues.
Everyone’s right - HubSpot wants clean integers, not doubles with decimals. But handling these API quirks manually gets old fast, especially with multiple date fields or bulk operations.
I hit the same wall during a customer onboarding project. Had dozens of date fields across different HubSpot objects, each with its own formatting needs. Wasted too much time debugging timestamps instead of actually building features.
Switching to an automation platform that handles conversions automatically fixed it for me. No more wrestling with JSON serialization or data type casting.
Latenode’s native HubSpot integration manages all timestamp formatting automatically. Just map your date fields and it converts everything to proper Unix timestamps. Works across contacts, deals, companies - any HubSpot object you’re updating.
Huge time saver when you’re juggling multiple date properties or complex transformations. Plus you get visual workflows instead of writing conversion methods.
Yeah, that .0 decimal is your problem. HubSpot’s datetime parser is picky about integer format. I had the same issue with contact imports - even though it’s mathematically the same number, the API validation sees text with a decimal and rejects it. Cast to long before serialization and you’re good.
Understanding the “Why” (The Root Cause):
Step-by-Step Guide:
Common Pitfalls & What to Check Next:
Still running into issues? Share your (sanitized) config files, the exact command you ran, and any other relevant details. The community is here to help!