Notice: Potential Breaking Changes in Week 41 (7-Oct-2026)

Announcements
1

:warning: Potential Breaking Change: Upcoming Changes to View-Based API Update Behavior (API)

Heads up: Starting October 7, 2026, view-based API requests will be required to follow the editing settings configured in your app.

This change affects how the Knack API authorizes update requests made through a view.

:sparkles: What’s Changing

Views must be configured for editing. Requests that update a record through a view will only succeed when that view allows editing, such as a Form view or a view with inline editing turned on. Views set up for display only will reject update requests with a 400 error.

Field-level edit settings will be enforced. If a field is set as not editable in a view, requests through that view can no longer update that field, even when other fields in the view are editable. The view will also no longer return editing options for that field, such as available choices for a connection field.

:warning: Who May Be Affected

Most apps won’t be affected. You may need to take action if you have custom code, an external integration, or an automated workflow that updates records through a view and either:

  • Sends updates to a view that is set up for display only, or

  • Writes to a field that is set as not editable in that view.

:white_check_mark: What To Do

If you rely on either pattern, update your setup to use one of these supported options:

  • Make the view or field editable, if users should be able to change it

  • Send the update through a Form view that includes the field (this can be a form hidden from users)

  • Use object-based API requests for secure server-side integrations

:warning: Potential Breaking Change: Improved Security for Filtered Connection Pickers (API)

Also arriving in week 41 (October 7, 2026): significant security improvements to connection field lookups.

Specifically, the undocumented endpoint GET /v1/scenes/scene_NN/views/view_NN/connections/field_NN is changing substantially. If you have a custom integration or process that uses this endpoint, we recommend migrating to a view-based API call to a table or search view that has access to the desired data. Documentation for view-based GET requests can be found here.

This change only affects the shape of the payload sent to Knack. The shape of the response from this endpoint does not change. Any code that reads the result of a connection picker lookup is not affected.

:new_button: New: Restrict POST for View-Based API (Settings → Security)

New: A new security setting is coming in week 41 (October 7, 2026) under Settings → Security that controls whether new records can be created through views designed for editing, such as Edit Record forms and search views with inline editing enabled.

Toggle Restrict POST for View-based API on or off to control whether your edit-intended views can be used to create new records via the API.

:locked: Built-In Rules

Behavior varies depending on when your app or account was created:

  • Existing apps: The setting defaults to OFF, so there is no change to your app’s current behavior. You can enable it at any time.

  • New apps: The setting defaults to ON, blocking record creation through edit-intended views out of the box.

  • New accounts after Oct 7: The restriction is always enforced and no toggle is available.

This setting gives you more control over how your app’s API behaves, helping prevent unintended record creation through views that weren’t designed for it.

2

cc: @LeighBerre96926 @CSWinnall @AC1 @MaxPagel93229 @StephenChapman @NormandDefayette_CortexRD @Callum.Boase

3

These scenarios can be found in your apps easily and quickly using Knavigator MCP.

You can hook it up to your AI agent, register your app(s) and then simply provide the URL of this forum post and ask it to check your apps.

Or use the prompt below:

Use knav to check my apps for the following:

Knack changes its view-based API on 7 Oct 2026 (week 41):
https://forums.knack.com/t/notice-potential-breaking-changes-in-week-41-7-oct-2026/20579

1. Updates (PUT) through a view. Knack: "Requests that update a record
   through a view will only succeed when that view allows editing, such as
   a Form view or a view with inline editing turned on. Views set up for
   display only will reject update requests with a 400 error." And: "If a
   field is set as not editable in a view, requests through that view can
   no longer update that field, even when other fields in the view are
   editable."

2. New records (POST) through a view. Knack: "Edit forms, inline-editable
   grids, search views, list views, and calendar views (calendar views
   without 'Allow adding events' enabled) will all reject POST requests."
   This applies when the setting "Restrict POST for View-based API"
   (Settings > Security) is on. It is OFF by default for existing apps,
   ON by default for new apps, and always on for accounts created after
   7 Oct.

3. Calls to the connection-picker endpoint
   GET /v1/scenes/scene_NN/views/view_NN/connections/field_NN.
   Its request payload changes.

Steps:
- Call knav_apps to list my registered apps.
- For each app, call knav_code with app_id and calls: true (one call per app).
- Using the facts knav returns for each call (method, view and its editing
  and adding settings, fields sent and whether each is editable there),
  decide which calls will fail under 1 or 2. List them with the line, HTTP
  method, scene and view, field, and the reason. For POSTs, say whether the
  app has "Restrict POST for View-based API" on, if knav can tell.
- List the calls whose target is only known at run time under
  "Check by hand".
- List any calls to the connection-picker endpoint separately.
- If an app has none of these, say so in one line.
- Do not change anything in my apps.

knav reads each app’s schema from Knack and reports the facts about every view-based API call, and your AI agent applies Knack’s rules to them. It does not look at Make, Zapier, Flows, server-side integrations, or code inside the KTL library. Treat the results as a starting point and test anything the check reports as affected.

I built Knavigator MCP. To use it, sign up at https://knav.avvera.ca, add your app ID and verify that you own the app.

4

Thank you @Kara and all Knack Team !!!

The implementation is perfect, even better than what I hoped for.
The KTL will not break anymore.

I’ve updated my code and documentation for new and existing users to stay aligned with this security update.

Norm

5

All of a sudden today, the main form several of my staff use all day is broken. I’m guessing it’s related to this? However there is no js related to this view. I’m getting a 400 Bad Request in the console. This is just a basic form to create a new record. Update: its ALL forms related to creating new records. How soon can this be fixed?!? I have 35 employees that can’t do their jobs now.

6

Why wasn’t this sent out as an email? Seriously guys. FFS.

7

This was a disruptive update. Every create form in our app started to fail this morning - each one returned a list of “[Field] is required” errors for fields that were not on the form at all.

What changed, in our testing: a create form must now supply a value for every field that is marked Required in the table it writes to. This applies to fields the form does not show, fields that a display rule hides, and fields that a record rule fills after submit.

Edit forms do not seem to be affected. Number fields and fields with a default value were not flagged for us.

What fixed it for us:

  1. Find the fields named in the error. For each one that a create form does not collect, open the field settings and turn off Required. This does not delete data. Your record rules continue to fill values as before.
  2. If you still need a field to be required on the forms where it appears, add a small Custom JavaScript check that blocks Submit when that input is visible and empty. Note: Classic custom JavaScript does not run in the Next-Gen live app.

This change stopped our operations without warning, and as far as I can tell it is not even disclosed in the week-41 notice. I recommend adding this change to the notice so that other users know where to look if their apps break. An email notification would also have been helpful.

8

I did that too, but Knack has resolved this issue now. Very disruptive indeed.

9

Hi all,

We are very sorry for the disruption to forms earlier today. It was not due to the changes listed above and we reverted the release as soon as we could.

As a side note, “Restrict POST for View-Based API” will go out next week (week 42) instead of this week.

What is posted here in forums is also sent via email by subscribing to our weekly update notes here.

Thank you again for your patience today, we know disruptions to forms are especially painful and we have written tests today to ensure that scenario will not happen again.

Cheers,
Kara