🚨 Bug / regression: Number fields with “.” decimal separator no longer recognized (API-imported data)

[Elise_Tarabiscode.com]

Hi Coda Makers,

I’ve run into a serious issue with Number fields that seems to have appeared in the last few days, particularly impacting data previously imported via the API.

Context

• My doc uses the following number format: 123 456,78

• For a long time, I imported numeric values via API using either . or , as the decimal separator

• Coda correctly interpreted those values as numbers, regardless of the separator

Current issue

All numbers that were previously imported with a dot (.) as the decimal separator are no longer recognized as numbers

• They now behave like text / invalid values

• This affects existing data, not just new API imports

• No changes were made on the API payload or the doc configuration

Impact

• Calculations are broken

• Historical data is effectively corrupted unless manually fixed

[Agile_Dynamics]

Are you sure the ‘.’ is the issue?
Your example shows numbers with spaces between the digits.
I would have expected that to be the cause of the problem.

[Diego_Delfino]

I experiencing the same issue.

Numbers like 6.5 are now not recognized anymore when using comma as a separator, while previously the software would recognize either ways.

@Agile_Dynamics the number format with space as thousands separator is one of the options in Coda

[Agile_Dynamics]

OK.

So this a BUG and needs to be reported to Coda Support via the ‘?’ on the bottom right of your screen.

That way a proper support ticket is raised for the support team to investigate.

Max

[Maxence_Walbrou]

@Agile_Dynamics

That way a proper support ticket is raised for the support team to investigate.

Hello there!
+1 on this bug. I already raised a ticket last week but got no answer yet …

If it can help, I used this "quick way” to correct tables where this happens :

Create a button with the following formula (for a table named “table” and number columns named “Column 1” & “Column 2”) :

table.Filter(
[Column 1].ContainsText(".")
OR [Column 2].ContainsText(".")
).ForEach(
Let(
CurrentValue,
element,
element.ModifyRows(
[Column 1], element.[Column 1].RegexReplace("\.", ","),
[Column 2], element.[Column 2].RegexReplace("\.", ",")
)
)

It basically :

• Get all rows where “Column 1” OR “Column 2” contain a “.”
• Iterate through those rows replacing “.” by “,”

---

2 questions I would like support to answer are :

1. Shall we change all our automations/API calls to Coda to use the final format directly (in my opinion, we shouldn’t, as formatting in docs may change, but should not break anything)?
2. If not, when will the fix be implemented? (This is a really urgent topic as any row added through API with decimals is created broken and must be fixed in our docs)

Regards

[Rickard_Abraham]

Oh this actually broke one of my docs, pretty concerning.

I have this recursive currency summarizer that used to work just fine

thisRow.[Prev Row].[Total Profit] + thisRow.Profit

But now it looked like this

Changing to (dot) delimiter in doc settings fixed it

[Maxence_Walbrou]

Hello there,

It has been more than 10 days since I raised this problem to support and got NO answer.
Does anyone have news on this concerning topic?
@Eric_Koleda, as this issue may related to API, do you have any advice?

The 2 questions I asked above remain the same:

1. Shall we change all our automations/API calls to Coda to use the final format directly (in my opinion, we shouldn’t, as formatting in docs may change, but should not break anything)?
2. If not, when will the fix be implemented? (This is a really urgent topic as any row added through API with decimals is created broken and must be fixed in our docs)

Thank you for your help

[Eric_Koleda]

@Maxence_Walbrou and others - This issue has been escalated to our engineering team and they are looking into it. They did recently make some changes to this part of the codebase, so I’m optimistic they’ll be able to get to the root of the issue quickly.

As for how to structure your API requests, the best approach would be to pass numbers as JSON number values, and not strings:

// Like this:
{
  "rows": [
    {
      "cells": [
        { "column": "Count", "value": 1234.56 }
      ]
    }
  ]
}

// Not this:
{
  "rows": [
    {
      "cells": [
        { "column": "Count", "value": "1234.56" }
      ]
    }
  ]
}

Passing a number value will work correctly no matter what the doc locale is set to. Note that JSON number values always use a period as the decimal separator, and do not support a thousands separator of any kind.

[Maxence_Walbrou]

@Eric_Koleda

This issue has been escalated to our engineering team and they are looking into it

Thank you @Eric_Koleda for your prompt response
I hope we’ll have news about the resolution very soon then

(I understand this may not be the ideal place for this feedback, but: I am really concerned we have to wait 10+ days without any support response for such a critical, non-cosmetic issue.

@Emma_Wyatt clarified that support wasn’t monitoring this community forum, but for this specific problem, we have no other solution to get informations (it seems support is totally off)…)

[Emma_Wyatt]

Hi, @Maxence_Walbrou.

Thank you for calling this out so candidly. I completely understand your frustration, and you’re right that it shouldn’t take 10+ days to get a response. It’s unacceptable, and I’m sorry for the experience.

The good news is that starting today, we’re rolling out updates that will allow us to more actively monitor this forum and surface critical issues faster, so situations like this don’t take as long to address going forward.

As for this particular issue, we’ve escalated it internally and are working to provide everyone with a concrete update as soon as possible. I’ve also sent you a DM to get a docID so our team can implement a fix in your docs.

Thank you for your patience. More to come very soon!

[Agile_Dynamics]

I am glad to see these responses and look forward to seeing better monitoring of this forum in the future.

I noticed this issue was lingering and cross-posted it to another platform where Codans seem to be more active. This prompted a Coda employee to take up the torch and escalate it internally.

I am glad it triggered a response, but I regret that it was delayed so long.

We are in uncertain times with Coda and Superhuman ‘in transition’; so we (Coda makers and influencers) are extremely sensitive to any hint that support for Coda is taking a back seat.

I am aware that major efforts are underway behind closed doors to improve Coda, but my clients and members of this forum do not have that awareness.

Hence, it is even more important at this time for Codans and Superhumans to exercise heightened situational awareness and an outward-facing focus. Now is not the time to be losing customers just before the new sweeping changes are ready for prime time.

Respect
Max

[Ruggy_Joesten1]

The days of query delays are a thing of the past! My mission is to make sure you have answers as fast as we can spin them up. An unintentionally rhyming post that I may, or may not, get tattooed on my body as an act of sustained accountability

[Diego_Delfino]

Hi everyone,

I opened a ticket few days ago regarding the issue, but I forgot to follow up here when I got replied.

Below is the answer I received from the Coda Support:

Update on Your Coda Support Ticket #7710121

Taru Neiman (Coda)

Jan 20, 2026, 10:02 AM PST

Hi Diego,

Wanted to follow up on your request.

Our team has confirmed that this is indeed a bug, and I have submitted a bug report on your behalf to our internal tracker for our engineers to investigate further.

We will update you when the bug has been fixed. Since turnaround time varies depending on severity, we’re unable to provide a clear timeline on when a fix will be available. I apologize for any inconvenience in the meantime.

Please let me know if there is anything else I can help with regarding this topic

Best,
Taru

[Ruggy_Joesten1]

Is this the most recent update/comms from the support team?

[Jason_Tamulonis]

Hi all,

Thanks again for bringing this issue to our team’s attention.

As Eric mentioned above, we strongly recommend always passing numbers to the API as number values and not strings.

Coda also has a very flexible type system. When you have a string in a number column that looks like a number, we treat it as if it were a number. When we launched international number formats in July, we required that your string inputs match your international number format to be considered a number.

However, there was a bug where strings that looked like numbers and used a period as the decimal separator were always coerced to a number, regardless of whether your selected number format was different.

We fixed this bug a few weeks ago, so some of these docs now show errors indicating that a string in a numeric column doesn’t match your format.

If this affects your docs, you can fix this with the following workaround:

• Go to Doc Settings → Region → Numbers

• Switch the Number format to 123,456.78 (This switch should rewrite lingering strings in number columns that match the new format)

• Switch the Number format back to the desired format for your locale.

Thanks,

Jason

[Piet_Strydom]

@Jason_Tamulonis

Coda also has a very flexible type system.

We’ve noticed…

It is a major source of frustration for many people using Coda for many years now. When we create a column with a certain type, that type is overwritten. Is it at all possible that we could get a column setting that would prohibit Coda from overriding the column type as set by the maker?

[Maxence_Walbrou]

Hello @Jason_Tamulonis, @Eric_Koleda,
Thank you for the response but the bug is still unresolved.

Here is a simple case to reproduce on your side with Make :

In Make, just use the module “Create a row” with a number
(Note : Make function “parseNumber” forces number format so that we send 12.4 and not “12.4” )
In Coda, you will see the number isn’t inserted correctly
(And yes, in Coda, switching the number format to 123,456.78 then back to 123 456,78 corrects the error in the table, but we get the same issue occurring in the next automation run…)

Do we agree this (~3 weeks) behavior is a bug and should be fixed?
(Note : 3 weeks ago, that exact same scenario would have inserted “12,4” in the table as a number).

[Eric_Koleda]

Hi @Maxence_Walbrou - Even with parseNumber, I believe Make is sending the value as a string. If you hover over the input it shows type “text”, and when you inspect the input bundle it’s also a string. parseNumber is converting the input to a number, but since the field is a text field it’s being converted back to a string and being sent that way.

It doesn’t appear that the Make integration supports sending raw number values. I think a workaround here is to use the formatNumber helper, which will convert the number to a string using the same decimal and thousands separator as the doc, allowing it to be parsed correctly.

You are correct that this is different behavior than three weeks ago. As @Jason_Tamulonis noted there was previously a bug that treated US formatted strings as numbers even when the doc used a different number format, and that bug has been fixed, resulting in this change in behavior.

[Maxence_Walbrou]

Thank you @Eric_Koleda for this detailed response

I was assuming ParseNumber was sufficient to get a “real” number, but you are right : Make’s module form seems to convert it into a string anyway

➔ I will then update my scenarios to fit the doc number format as you suggest.

Thank you again for the investigation.
Kind regards