Troubleshooting Your Knack Connection
Fix the most common problems when a custom frontend built in Lovable, Base44, or Claude Code connects to Knack, including sign-in failures, CORS errors, filters that return every record, and empty screens with no error.
What You'll Learn
This article covers the most common problems when a custom frontend connects to Knack, what causes each one, and how to fix it. Several of these problems look like something else, so each section starts with what you see and explains what's actually happening.
Start with These Three Checks
Most connection problems come down to one of these. Check them before anything else.
- Are you testing on your published app? Sign-in doesn't complete inside a frontend builder's preview. Open your published address in a normal browser tab.
- Is your app pointed at the right Knack app? Ask your frontend builder which Knack application ID it uses, and compare it to the one in your Knack Builder.
- Are you signed in as the role you think? Sign out, sign back in with a test login for one role, and try again.
Sign-In Fails in Your Frontend Builder's Preview
What you see: You reach the Knack sign-in screen, but signing in fails, loops, or shows a "session expired" message.
What's happening: The preview panel next to your frontend builder's chat isn't a full browser, and the handoff back from Knack doesn't complete there. This has been seen in every frontend builder we've tested.
How to fix it: Publish your app and test sign-in on the published address in a normal browser tab.
Sign-In Fails with a Redirect Address Error
What you see: An error saying the redirect address isn't registered, often naming the address.
What's happening: Knack only sends users back to addresses registered for your app's sign-in. The address your app sent doesn't match one on the list. The difference is often small, like http instead of https, or a trailing slash.
How to fix it: Ask your frontend builder to show you the exact address it sends, then compare it character by character with what was registered. Knack requires https. For Claude Code apps, see Troubleshooting Claude Code and Knack.
Requests Fail with a CORS Error or "Failed to Fetch"
What you see: Your app can't load data. The browser console shows a CORS error or "Failed to fetch," usually pointing at a Knack address.
What's happening: This looks like a network or permissions problem, but it's usually one of two mistakes in how your app talks to Knack.
- The API address is missing
/v1. The request goes to the wrong address, gets redirected to Knack's website, and the browser blocks it. - The sign-in token is sent in the wrong format. Without the word
Bearerin front of the token, Knack rejects the request in a way the browser reports as a CORS error.
How to fix it: Ask your frontend builder to check both.
Read-only. Make no changes yet.
1. Show me the base address your app uses for every Knack request. It should be exactly https://api.knack.com/v1, with no /v1 added again on any path.
2. Show me the exact Authorization header your app sends. It should be "Bearer " followed by the user's token.
Tell me what you found and what you would change. Wait for my approval.Every Filter or Tab Shows the Same Records
What you see: Your app's tabs, filters, or status views all show the same list with the same count. Filtering looks broken.
What's happening: The filter is being sent in a format Knack can't read. Knack doesn't reject it with an error. It ignores the filter and returns every record. A common cause is the filter being encoded twice.
A broken filter can show people records they shouldn't seeIf your screens rely on a filter to show each person only their records, a broken filter shows everything. Data Access Control is what actually protects records. Make sure it's set up and enforced, and don't rely on filters for security.
How to fix it: Ask your frontend builder to check how filters are sent.
Every filter in my app returns the same records. Check how filters are sent to Knack.
The filter should be JSON.stringify of the filter object, passed once to URLSearchParams. It should not also be run through encodeURIComponent.
Show me what you find and what you'd change. Wait for my approval. After the fix, list one filter that should return fewer records, and tell me both counts: with the filter and without it.The test only proves the fix if the two counts are different.
Screens Are Empty with No Error
What you see: You sign in and the screen loads, but it's empty or shows zeros. No error appears.
What's happening: When access rules block someone from reading records, Knack returns an empty list, not an error. An empty screen can mean any of these.
- Access rules don't allow this role to see the records. Check the role's settings in the Data Access grid.
- The records are owned by someone else. Imported records and records added through the MCP Server are owned by the App Builder system user. See Who Owns a Record Created from a Custom Frontend.
- The screen depends on a connected table the role can't read. See Allowing Connected Field Selection Without Table Access.
- Your app hides errors. Some apps catch an error and show an empty screen instead. Ask your frontend builder to show a visible error whenever a Knack request fails.
To tell a blocked read from a truly empty table, sign in as a role that should see the records and compare. See Checking That Your Access Rules Actually Work.
Saving a Change Fails with Access Denied
What you see: Adding, editing, or deleting a record fails. Your app may show a 403 or "access denied" error.
What's happening: Unlike reads, blocked changes return an error. The role doesn't have permission for that action on that record. Edit Only lets a role add, edit, and view records but not delete them.
How to fix it: Check the role's access in the Data Access grid for both Owned by User and All Other Records. If the user should be able to change a record they don't own, the record's owner or the role's access needs to change.
A New User Isn't Created, but Your App Says It Worked
What you see: Your app adds a user and reports success, but no new user appears in Knack.
What's happening: In our testing, creating a record in a user role table from a custom frontend returned a success response without creating anything.
How to fix it: Create user accounts through Knack instead: Knack's hosted sign-up page, the Knack Builder, or an import. See Choosing a Default User Role for a Custom Frontend for setting up sign-up.
Users Can't Sign In Because Their Account Isn't Active
What you see: A user enters the right password, but Knack says the account is inactive or pending approval.
What's happening: Knack checks the user's account status at sign-in. Pending and inactive users can't sign in. This is working as intended.
How to fix it: Change the user's status to Active in the Knack Builder once they should have access.
Your Frontend Builder Says It's Done, but Nothing Changed in Knack
What you see: Your frontend builder reports that it created a table, field, record, or setting, but you can't find it in the Knack Builder.
What's happening: AI tools sometimes report a change as complete when it didn't happen, or made it in a different app.
How to fix it: Ask which Knack app it changed and what it called. Then check the Knack Builder yourself after every change, not just when something looks wrong.
Ask Your Frontend Builder to Diagnose a Problem
When you're not sure which of these you're seeing, start with a read-only diagnosis. It keeps the builder from changing things while it guesses.
Read-only. Make no changes.
[Describe what you see, including any exact error text.]
Find the cause, starting with the simplest checks:
1. Which Knack application ID does the app use?
2. What base address and Authorization header does it send?
3. What exact request is failing, and what did Knack return (status and response body)?
4. Is any error being caught and hidden instead of shown?
Report what you found and what you'd change. Wait for my approval before changing anything.Quick Reference
| What you see | Likely cause | Where to look |
|---|---|---|
| Sign-in fails in preview | Preview can't complete the handoff | Test on your published app |
| Redirect address error | Address doesn't match what's registered | Compare addresses character by character |
| CORS error or "Failed to fetch" | Missing /v1 or missing Bearer | Base address and Authorization header |
| Every filter shows the same records | Filter encoded twice | How filters are sent |
| Empty screen, no error | Access rules, ownership, or hidden errors | Data Access grid, Owned By, error handling |
| 403 when saving | Role lacks permission for that action | Data Access grid |
| New user not created | User accounts created from the app | Use Knack's sign-up page or the Builder |
| Builder says done, nothing changed | Unverified change | Check the Knack Builder |
For developersA denied filtered read returns 200 with
total_records: 0, an emptyrecordsarray, andrecast: true. A denied write returns 403 witherrorCode: access_control_update_forbidden. A request with a malformed Authorization header returns 403 without CORS headers, so browser code can't read the body. Check the Network tab's response instead of the console. The correct header shape isAuthorization: Bearer <token>withX-Knack-Application-Id: <appId>.
Next Steps
- Runtime Data API: See the sign-in flow, record endpoints, and error responses in detail.
- Checking That Your Access Rules Actually Work: Prove Knack is enforcing your access rules.
- How to Ask Your Frontend Builder to Work with Knack: Write prompts that point your builder at the right app, table, and field.
Updated 3 days ago