Bizarre Rounding Issue When Posting to "/crm/v3/objects/line_items/batch/update"

Developer Support APIs & Integrations
,
1

Hello all-

Has anyone seen a strange rounding issue when posting values to “/crm/v3/objects/line_items/batch/update”?

I have an instance where I am sending a value to two decimal places, but receiving a 400 error that the value is invalid.

Value I send: [discount] => -0.09

API Error Response: Exception = [400] Client error: `POST https://api.hubapi.com/crm/v3/objects/line_items/batch/update` resulted in a `400 Bad Request` response:
{“status”:“error”,“message”:“Property values were not valid: [{\“isValid\”:false,\“message\”:\”-0.0899999999999999966693 (truncated…)

I cannot figure out why -0.09 turns into -0.89 repeating.

If anyone has any insights that would be fantastic, thank you!

Dave

2

Hey, @DaveLinderman :waving_hand: Can you share the full request body, please? I’d like to try to reproduce this in my test portal, and I want to make my test as close to yours as possible.

Thanks! — Jaycee

3 
line items = Array
(
 [0] => Array
 (
 [id] => 27410380823
 [properties] => Array
 (
 [price] => 7.5384615384615
 [discount] => -0.09
 )
 )
)
4

Hey @DaveLinderman :waving_hand: Does the same or similar error happen when you remove the negative value and instead send it as “0.09” for “discount”?

Using Postman, when I send it as “-0.09”, I get a validation error (but not the floating-point weirdness). And when I send it without the “-” it is accepted. I ask because when we enter a discount in-app, we don’t include the “-” as the system handles the discounting for us.

Example:

PATCH https://api.hubapi.com/crm/v3/objects/line_items/27857501610

{
 "properties": {
 "discount": "0.09"
 }
}

Response

{
 "id": "27857501610",
 "properties": {
 "amount": "11999.82",
 "createdate": "2025-01-15T18:28:00.867Z",
 "discount": "0.09",
 "hs_acv": "143997.84",
 "hs_arr": "143997.84",
 "hs_lastmodifieddate": "2025-01-15T18:31:54.044Z",
 "hs_margin": "11999.82",
 "hs_margin_acv": "143997.84",
 "hs_margin_arr": "143997.84",
 "hs_margin_mrr": "11999.82",
 "hs_margin_tcv": "287995.68",
 "hs_mrr": "11999.82",
 "hs_object_id": "27857501610",
 "hs_object_source": "INTEGRATION",
 "hs_object_source_id": "959085",
 "hs_object_source_label": "INTEGRATION",
 "hs_post_tax_amount": "11999.82",
 "hs_pre_discount_amount": "12000.00",
 "hs_recurring_billing_period": "P24M",
 "hs_tcv": "287995.68",
 "hs_term_in_months": "24",
 "hs_total_discount": "0.18",
 "quantity": "2",
 "recurringbillingfrequency": "monthly"
 },
 "createdAt": "2025-01-15T18:28:00.867Z",
 "updatedAt": "2025-01-15T18:31:54.044Z",
 "archived": false
}

Talk soon! — Jaycee

5

Ahhhh, great call. I got so hung up on the fact that the error was showing a different number than I was passing that I glossed over the fact that it was sending a negative and not a positive. This is due to the integration interpreting a price INCREASE as a negative discount instead of its original intended use as a discount-only mechanism. Thank you for trying this in your portal, and getting my focus back on track!

6

Hey Dave! I’m glad that got us back on track. I was thinking about it while testing and wondered if a negative discount in this context would actually be an increase (as you noted). But because it wouldn’t validate, I figured it was a moot point.

Have a fantastic day! — Jaycee