Heads up! Small chance of a potentially breaking change

API & Custom Code
1

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.

2

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?

3

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

4

@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

5

Please consider giving us more time. This is major change and 3 days is not long enough.

6

@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.

7

@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.

8

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.

9

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.

10

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

11

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