# Heads up! Small chance of a potentially breaking change **URL:** \ **Category:** API & Custom Code\ **Created:** [September 18, 2026, 10:39pm UTC](https://forums.knack.com/t/heads-up-small-chance-of-a-potentially-breaking-change/20571 "2026-09-18T22:39:44Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Kara](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/kara/32/2717_2.png) [@Kara](https://forums.knack.com/u/Kara)\ **Post date:** [September 18, 2026, 10:39pm UTC](https://forums.knack.com/t/heads-up-small-chance-of-a-potentially-breaking-change/20571/1 "2026-09-18T22:39:44Z")
We’re fixing an edge case where edit-only views, including edit forms, inline-editable tables, search results, list views, and calendar views, could be used to create new records by sending a POST request directly to the view’s endpoint, bypassing the intended form entirely. This change will be in next week’s regularly scheduled release. This was not something that could happen through normal use of the Live App. It required a developer to intercept a legitimate edit request and manually modify it (changing the method from PUT to POST and stripping the record ID). The server will now check whether a view is actually capable of creating records before allowing a POST. Edit forms, inline-editable grids, search views, list views, and calendar views (calendar views without “Allow adding events” enabled) will all reject POST requests. It’s possible this could be a breaking change for any custom code or integration that sends POST requests to view-based endpoints associated with edit forms or inline edit views. If you’re using the API to create records, you should be sending POST requests to an add record form’s endpoint or using the object-based API (/api/v1/objects/{object\_key}/records). View-based create calls that were previously accepted will now return an error. ---
**Author:** ![StephenChapman](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/stephenchapman/32/1759_2.png) [@StephenChapman](https://forums.knack.com/u/StephenChapman)\ **Post date:** [September 19, 2026, 12:01am UTC](https://forums.knack.com/t/heads-up-small-chance-of-a-potentially-breaking-change/20571/2 "2026-09-19T00:01:41Z")
For people’s reference, I’ve done this in the past to `GET` all form values from an edit form view, and then performed a `POST` in this same edit form view with the duplicated body to essentially copy the record. @NormandDefayette_CortexRD just checking KTL doesn’t utilise this at all? ---
**Author:** ![NormandDefayette\_CortexRD](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/normanddefayette_cortexrd/32/855_2.png) [@NormandDefayette\_CortexRD](https://forums.knack.com/u/NormandDefayette_CortexRD)\ **Post date:** [September 19, 2026, 3:39pm UTC](https://forums.knack.com/t/heads-up-small-chance-of-a-potentially-breaking-change/20571/3 "2026-09-19T15:39:57Z")
Thanks @StephenChapman for the ping, and @Kara for the heads-up. Unfortunately yes — the KTL relies on this, and in more than one place. A bit of history: I discovered this particularity of the API by pure coincidence back in 2019, while experimenting with view-based API calls. I found it pretty cool and very useful — creating records with the logged-in user’s token, no API key exposed, page access rules still applying — so I have used it in several places since. Not only in the KTL, but also in app-specific code. In the KTL, these features create records by sending a POST through a **grid** : - **Bulk Operations – Copy** (duplicate records from a grid) - The **`_cpyfrom`** keyword in “add” mode - **Account Logs** (activity, navigation, errors — running in the background for every user) - First-time creation of **App Settings** rows (KTL versions, Public Filters) and legacy **User Filters** - **App Tasks** Edit, delete and form-based features are not concerned. My problem is not the code, it is the reach. The KTL runs in a large number of production apps, used by thousands of end users, and **I have no way to contact the builders** — no email list, only my GitHub Discussions page. The fix on my side requires each builder to go back in the Builder and add new “add record” forms wherever these features are used. A KTL release alone can’t do that, and one week is not enough for that message to get around. Most people will simply discover that things stopped working. So I’d like to ask Knack to consider the following: 1. **Hold this change for Classic apps** , at least for a few weeks. That gives me time to implement the fixes and write the documentation. It also gives the other builders time to find the impacts of this change in their own code — I only saw this post because Stephen tagged me, so I’m probably not the only one who missed it. 2. A simple permanent solution: **a checkbox per view in the Builder — “Allow creating records through the API”** — off by default, with no change to the view itself. It only tells the server to let the POST through for that view. Your new rule already works this way for calendars, which accept a POST when “Allow adding events” is enabled. Your fix stays fully in place everywhere else, and the builder opts in, view by view, where it’s needed. Useful well beyond the KTL. 3. Going one step further with the same checkbox, if you’re interested: I understand the principle that the API should not do what the view itself can’t do — fair enough. So why not go the other way around and let the view do it? The checkbox becomes **“Allow adding records”** and also adds an “Add row” [+] button to the grid, as many grid products have. The view can then legitimately create records, and the API is in sync with it. More work on your side than option 2, I assume, but a nice feature for everyone. I’m following up by email with the technical side — error handling on rejection, and a way to identify the concerned apps — and I’m available for a meeting anytime. Whatever is decided, I’ll publish a KTL update and a clear procedure for KTL users. Norm ---
**Author:** ![CSWinnall](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/cswinnall/32/3631_2.png) [@CSWinnall](https://forums.knack.com/u/CSWinnall)\ **Post date:** [September 19, 2026, 5:50pm UTC](https://forums.knack.com/t/heads-up-small-chance-of-a-potentially-breaking-change/20571/4 "2026-09-19T17:50:49Z")
@Kara @NormandDefayette_CortexRD This is not an edge case and is utilised by multiple apps. 1 working day is not long enough to fix all our apps and the KTL will break. @Kara we need longer to adjust our code, seriously a week? Craig ---
**Author:** ![CSWinnall](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/cswinnall/32/3631_2.png) [@CSWinnall](https://forums.knack.com/u/CSWinnall)\ **Post date:** [September 19, 2026, 5:54pm UTC](https://forums.knack.com/t/heads-up-small-chance-of-a-potentially-breaking-change/20571/5 "2026-09-19T17:54:25Z")
Please consider giving us more time. This is major change and 3 days is not long enough. ---
**Author:** ![CSWinnall](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/cswinnall/32/3631_2.png) [@CSWinnall](https://forums.knack.com/u/CSWinnall)\ **Post date:** [September 19, 2026, 6:43pm UTC](https://forums.knack.com/t/heads-up-small-chance-of-a-potentially-breaking-change/20571/6 "2026-09-19T18:43:46Z")
@Kara Why is this even an issue. We just have to replace one view with another. There is not even a security issue. All it meant was having a single view do 2 jobs instead of 2 views for 2 jobs. If I am mistaken let me know. 3 days is not enough notice for a MAJOR Chance (NOT SMALL Chance) of a breaking change. ---
**Author:** ![CSWinnall](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/cswinnall/32/3631_2.png) [@CSWinnall](https://forums.knack.com/u/CSWinnall)\ **Post date:** [September 19, 2026, 9:00pm UTC](https://forums.knack.com/t/heads-up-small-chance-of-a-potentially-breaking-change/20571/7 "2026-09-19T21:00:15Z")
@Kara @JohnKaras Why was this so last minute? Thanks to @NormandDefayette_CortexRD @StephenChapman or I would not have known. This is not a small chance of breaking change this is a major change to advertise on a Friday night. This allows us 1 working day to fix and test. How does this affect forms where the first submit is a create? Please sort this out. You are making it harder and harder to tell our users to stay with knack. In regards to your fix most views we use for api are not used by front end users or we would not need custom code. If you don’t want users to use code then you shouldn’t allow it. With AI the way it is knack is being left in the past. The fact you have so little regard for your users says volumes. Sorry for the rant but I found this out on a Saturday night and I now have to work all day on a Sunday. ---
**Author:** ![Kara](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/kara/32/2717_2.png) [@Kara](https://forums.knack.com/u/Kara)\ **Post date:** [September 19, 2026, 10:25pm UTC](https://forums.knack.com/t/heads-up-small-chance-of-a-potentially-breaking-change/20571/8 "2026-09-19T22:25:47Z")
Hey @CSWinnall and @NormandDefayette_CortexRD Thanks for the feedback, we did not realize that this was more than an edge case and we’ll have a conversation with the team on Monday and follow up. ---
**Author:** ![LeighBerre96926](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/leighberre96926/32/4896_2.png) [@LeighBerre96926](https://forums.knack.com/u/LeighBerre96926)\ **Post date:** [September 19, 2026, 11:11pm UTC](https://forums.knack.com/t/heads-up-small-chance-of-a-potentially-breaking-change/20571/9 "2026-09-19T23:11:37Z")
Kara and John, as a long time Knack Builder it is concerning to me that Knack is making these kinds of unilateral calls without understanding their own user base and how they use your product. As Craig said in his rant, its like you do things to purposely make it harder for long term users to choose to stay with Knack. In particular, why is Norm not on a hotline with you guys? You know KTL is used by literally thousands of apps because it fills a significant gap in your product. (The same gap that prevents me from moving to next gen). Develop an appreciation for that and understand the implications of your ideas in that context.. In particular I urge you to strongly consider Norm’s suggestion of using this as a way to extend the value of the product instead of shrinking it. ---
**Author:** ![NormandDefayette\_CortexRD](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/normanddefayette_cortexrd/32/855_2.png) [@NormandDefayette\_CortexRD](https://forums.knack.com/u/NormandDefayette_CortexRD)\ **Post date:** [September 20, 2026, 1:21am UTC](https://forums.knack.com/t/heads-up-small-chance-of-a-potentially-breaking-change/20571/10 "2026-09-20T01:21:05Z")
Thanks @Kara, much appreciated. And thanks @CSWinnall and @LeighBerre96926 for weighing in. Craig, about your question on forms where the first submit is a create. If you mean a regular “Add record” form, it’s not concerned, those keep accepting POST. But if you mean sending a POST through an **edit** form to create a record that doesn’t exist yet, then as I read Kara’s post, that’s the same family as Stephen’s case and mine: edit forms are on the list of views that will reject POST. @Kara, can you confirm? One thought for Monday’s discussion. In all my cases, in the KTL and in app-specific code, these API calls are made by a **logged-in user** , on login-protected pages, with the page’s access rules applying. That user can already edit records through the same view, which is a lot more powerful than adding one. So if the concern is public pages, where no login is required, then blocking POST there makes total sense. No problem at all on my side, it’s even a good thing. That alone might close the risk without breaking anything for anyone. To be clear about my preference: leave things as they are for logged-in users, and block POST on public pages. If that’s not possible, the basic per-view checkbox (my option 2 above) would do. And forget my option 3, the “Add row” button. Too much work for what it brings. To the other builders: if your code creates records through grids, edit forms or search views, please say so here, and mention whether it’s behind a login or not. The more concrete cases Knack has before Monday, the better the decision will be. I’m sending Knack the technical details by email before then. Norm ---
**Author:** ![AC1](https://avatars.discourse-cdn.com/v4/letter/a/c77e96/32.png) [@AC1](https://forums.knack.com/u/AC1)\ **Post date:** [September 20, 2026, 8:53am UTC](https://forums.knack.com/t/heads-up-small-chance-of-a-potentially-breaking-change/20571/11 "2026-09-20T08:53:59Z")
I agree that this is not an edge case. I manage at least seven Knack apps that I will now need to fully audit (not what I had planned for my Sunday) to understand the extent of the impact, but I already know that several of them will not function correctly if this change goes ahead as planned. All of these apps also rely heavily on KTL, so the wider impact of this change on KTL functionality is a significant concern. I quite often use grid view endpoints to create records via POST requests. In many cases, there is no need for an add form because these are background records that the user would never create manually. A good example is an audit trail: as Knack does not provide a way to display edit history to front-end users (in Classic), we have to create our own audit records so this information can be shown within the Live App. All of my affected use cases are on login-protected pages. I also think the way this was communicated is very poor. The forum post was published on a Friday evening, and many builders will not see it before the release. A change with the potential to break production apps should really have been emailed to all builders, with enough notice to audit, update and properly test their apps. If I had not been alerted to this forum post, several of the apps I manage could simply have stopped working on Tuesday without me knowing why. I appreciate that the team is now discussing it, and I hope the change will be postponed or adjusted to allow POST requests for logged-in users or through a per-view setting, as @NormandDefayette_CortexRD has suggested. @Kara I eagerly await a respone. Thanks Amanda ---
**Author:** ![CSWinnall](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/cswinnall/32/3631_2.png) [@CSWinnall](https://forums.knack.com/u/CSWinnall)\ **Post date:** [September 20, 2026, 4:59pm UTC](https://forums.knack.com/t/heads-up-small-chance-of-a-potentially-breaking-change/20571/12 "2026-09-20T16:59:27Z")
Hi Kara Apologies for the tone of my messages as I said I found out late Saturday and I was in full panick mode. We audited our apps and we will have to create at least 35 endpoints plus finding ways round the KTL and adjusting our code to get and put and post to different views. The main thing for us is using tables to get put and post to. We rarely use forms for this as it keeps it all in one place. I appreciate you discussing it and I hope you at least postpone this change and improve your communication for any breaking change even if it is a small chance of a breaking change. Craig ---
**Author:** ![MaxPagel93229](https://avatars.discourse-cdn.com/v4/letter/m/ecc23a/32.png) [@MaxPagel93229](https://forums.knack.com/u/MaxPagel93229)\ **Post date:** [September 20, 2026, 8:37pm UTC](https://forums.knack.com/t/heads-up-small-chance-of-a-potentially-breaking-change/20571/13 "2026-09-20T20:37:41Z")
Hey @Kara Adding a voice here to this from an end users perspective. To be transparent our app uses KTL and Craig/Amanda’s work extensively. That being said waking up to a panic from our dev team does not give me confidence in knack as a product. Knack has been underwhelming me as a customer for quite some time and when issues like this pop up it adds fuel to the fire to reconsider our use of the platform. The ignorance displayed by the post title speaks volumes as others have said: it does not sound like your team knows how its product is being used. ---
**Author:** ![StephenChapman](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/stephenchapman/32/1759_2.png) [@StephenChapman](https://forums.knack.com/u/StephenChapman)\ **Post date:** [September 20, 2026, 11:03pm UTC](https://forums.knack.com/t/heads-up-small-chance-of-a-potentially-breaking-change/20571/14 "2026-09-20T23:03:57Z")
@CSWinnall @AC1, @NormandDefayette_CortexRD (and everyone else) - for more clarity, do you use the `POST` endpoint on grid views where inline editing is enabled, disabled, or both? I just tested on a **non-inline editable grid view** , and it still successfully posted a new record via the API. The same occurs on **list views** , **search views with list results** , and **search views with non-editable grid results** \*\*. I also tested `PUT` on the same set of non-editable views, and it blocked me from doing so, which I believe should also be the behaviour for `POST` requests. I am in everyone else’s boat on still having the option (ideally a toggle in the Security settings) to allow a `POST` on ‘editable’ views, but to allow this behaviour on non-editable views does not sit well with me from a security perspective. ---
**Author:** ![LeighBerre96926](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/leighberre96926/32/4896_2.png) [@LeighBerre96926](https://forums.knack.com/u/LeighBerre96926)\ **Post date:** [September 21, 2026, 1:44am UTC](https://forums.knack.com/t/heads-up-small-chance-of-a-potentially-breaking-change/20571/15 "2026-09-21T01:44:44Z")
Yes I would agree with that. To allow post the scene should be login and role protected (so you know the user should be there) and via a view that is supposed to be making changes to the data. It’s possible that even that combination might not be acceptable in some instances. It could be argued that an edit screen should not necessarily allow create … I can come up with many circumstances where creating a new record (eg scheduling a bank payment) might not be desirable. But if there is builder control over that as proposed then it is informed consent, not an unknown risk. ---
**Author:** ![CSWinnall](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/cswinnall/32/3631_2.png) [@CSWinnall](https://forums.knack.com/u/CSWinnall)\ **Post date:** [September 21, 2026, 6:28am UTC](https://forums.knack.com/t/heads-up-small-chance-of-a-potentially-breaking-change/20571/16 "2026-09-21T06:28:09Z")
@StephenChapman I didn’t realise you could still post to a view with inline edit off. This is an issue which should be resolved. We only ever post to grid views with inline edit on. List, Details should not have post allowed as these are non editable views. To be honest it never even occurred to me to try it. I think the primary issue here will be grids with inline edit turned on. That is also the main issue in the KTL. That does not mean other devs do not use the other views but it would surprise me if they do use them as its counter intuitive to post to a non editing view. My biggest issue here is still the fact that this was posted on a forum rather than sent out weeks ago. I can understand why they want to tighten this up as we allow external applications to use get requests to tables with inline editing off and now realise that they can post data to the table which is not right. It’s the lack of time when letting us know of a major breaking change. Craig ---
**Author:** ![CSWinnall](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/cswinnall/32/3631_2.png) [@CSWinnall](https://forums.knack.com/u/CSWinnall)\ **Post date:** [September 21, 2026, 6:50am UTC](https://forums.knack.com/t/heads-up-small-chance-of-a-potentially-breaking-change/20571/17 "2026-09-21T06:50:18Z")
![4639](https://us1.discourse-cdn.com/flex020/uploads/knack/original/2X/2/2c49073affd20a4c66abde76b8470fb3b42a7b3c.jpeg) As an aside, Just looking at the docs and Knack do say PUT to lists with inline editing turned on??? ---
**Author:** ![StephenChapman](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/stephenchapman/32/1759_2.png) [@StephenChapman](https://forums.knack.com/u/StephenChapman)\ **Post date:** [September 21, 2026, 7:41am UTC](https://forums.knack.com/t/heads-up-small-chance-of-a-potentially-breaking-change/20571/18 "2026-09-21T07:41:39Z")
@CSWinnall > I didn’t realise you could still post to a view with inline edit off. This is an issue which should be resolved. I was also surprised that this was possible, and I hadn’t thought to try it either. > As an aside, Just looking at the docs and Knack do say PUT to lists with inline editing turned on??? You can’t even inline-edit a list view, so this seems to be an oversight in documentation. > My biggest issue here is still the fact that this was posted on a forum rather than sent out weeks ago. Agreed. * * * Here’s what I hear and recommend. Keen to hear feedback: | View | GET | POST | PUT | DELETE | | --- | --- | --- | --- | --- | | Details | Y | N | N | Y (with delete action) | | Grid | Y | Y (with inline edit) | Y (with inline edit) | Y (with delete action) | | List | Y | N | N | Y (with delete action) | | Search (grid) | Y | Y (with inline edit) | Y (with inline edit) | Y (with delete action) | | Search (list) | Y | N | N | Y (with delete action) | | Form (insert) | Y | Y | Y | N | | Form (update) | Y | Y | Y | N | | Calendar | Y | Y (with inline edit) | Y (with inline edit) | Y (with delete action) | ---
**Author:** ![CSWinnall](https://sea2.discourse-cdn.com/flex020/user_avatar/forums.knack.com/cswinnall/32/3631_2.png) [@CSWinnall](https://forums.knack.com/u/CSWinnall)\ **Post date:** [September 21, 2026, 9:29am UTC](https://forums.knack.com/t/heads-up-small-chance-of-a-potentially-breaking-change/20571/19 "2026-09-21T09:29:11Z")
I agree with this. Inline edit is the toggle no need for a new toggle and using the column edit toggle to allow/disallow POST PUT on a column level. ---
**Author:** ![AC1](https://avatars.discourse-cdn.com/v4/letter/a/c77e96/32.png) [@AC1](https://forums.knack.com/u/AC1)\ **Post date:** [September 21, 2026, 9:31am UTC](https://forums.knack.com/t/heads-up-small-chance-of-a-potentially-breaking-change/20571/20 "2026-09-21T09:31:56Z")
Hi Stephen, I completely agree with your recommendation. Let’s hope Knack do too and get back to us soon, so we know whether we need to update all our apps over the next 30 hours, to prevent them from breaking. Amanda [Next page](https://forums.knack.com/t/heads-up-small-chance-of-a-potentially-breaking-change/20571.md?page=2)