SaaS
Now this has jumped again, next row is coming up as 128 under the Internal Stock Id column
Hey @markusername, do you happen to have any API calls running?
Hi Olga, i have the table connected to make.com. does this affect autonumbering?
That is a well know old topic.
Please see also Adding new rows screws up Autonumber and Row ID# - #34 by FrancoisS
@olgatrykush it would be great if you can give an update as requested from @Edouard in the old thread in Nov. 2025
@markusername yes, that might be the reason. It’s possible that Make is sending API requests and something is going wrong during row creation.
In such cases, the system attempts to create a new row and assigns it a unique ID, but if the process fails, the row isn’t fully created. However, Baserow still considers that ID as used. This is intentional and helps prevent ID duplication.
The same principle applies when multiple collaborators try to create rows at the same time — this mechanism (known as a race condition safeguard) ensures that two rows don’t end up with the same ID.
Since your table is connected to Make, it’s possible that some API requests are failing, which could explain the skipped numbers in row IDs.
Could you check the Make logs to see if there are any errors during those requests?
Hi @olgatrykush , I’ve got make.com basically set to ‘watch’ the Baserow table for any newly created rows, that’s it. I only run the make ‘scenario’ though the odd time so it’s not constantly pinging baserow or anything. No errors in the Make logs, all runs fine, the ‘watch’ operations in Make complete successfully and works well. Only issue as I say is the auto number function in the baserow table just isn’t working as expected.
Hey @markusername, I see now. It looks more similar to the @be_Berlin issue here: After moving to own server Autonumber started at randomly earlier point - #3 by be_Berlin
I’ve asked the dev team for some assistance here. I’ll keep you posted 
I don’t mean to be a bother, but I still think this thread should cover a separate issue.
Inconsistent auto-numbering also occurs even if the workspace hasn’t been imported or exported beforehand. This also seems to happen when no automation is accessing the table ‘from outside’ to create new rows.
I think the team should look into this recurring error of inconsistent auto-numbering.
Reliable auto-numbering is particularly important when row creation may be interrupted and an inconsistent row_ID must be accepted.
Yeah would be brilliant to have reliable / consistent auto numbering working for fields.
Hey @markusername, it’s actually a bug, and we’re working on the fix. Thanks for reporting the issue 
Brilliant stuff, thanks @olgatrykush
