It’s definitely strange, but I don’t think it could lead to the unexpected deletion of a record from the wrong table (correct me if I’m wrong here). Every record has a unique ID, that is unique regardless of table. There will never be a Post and a Comment that have the same recordID, only preceded by a different table name. So for this to be an issue, you’d have to actually call the wrong recordID, along with the wrong table, in order to delete a completely unexpected record.

Fair enough, and I think you are right that two records cannot share the same ID even if they’re in other tables. It actually came up as I was working on a Proxy API that allows users to Delete records from one table, but only read from another table. Because of this bug, users can get around my table access rules.

Ya, that could be a problem.

Don’t quote me, but I think somewhere around here is a comment from Kasra saying that while records almost certainly have unique values, there’s nothing that enforces unique-ness…

To clarify: record IDs in a base are currently guaranteed be unique, even across different tables

We may change that in the future, so it’s best not to rely on the uniqueness, but we won’t change that guarantee until this issue is resolved in a future API update.

Sorry for this strange behavior in the current API!

Not a big deal, and thanks for confirming the issue. Good to know I wasn’t just messing something up.

Is there any timeline or roadmap for future API improvements? I love the API, so I’d love to know when it’s being updated.

This is indeed odd, and something we intend to fix in the next version of the API. We can’t fix it now, unfortunately, because we might break someone who is relying on this (strange) behavior.

We don’t have a public roadmap for API improvements, but it’s definitely something we’re working on!