); } } ``` Options [#options] ```tsx ``` * `fileName` — pin the bridge to a specific FileMaker file. Useful when more than one file is connected. * `fmMcpBaseUrl` — base URL of the local FM MCP daemon. Defaults to `http://localhost:1365`. * `wsUrl` — WebSocket endpoint for script forwarding. Computed from `fmMcpBaseUrl` if not set. * `debug` — log bridge activity to the browser console. The Next.js bridge is development-only, like the Vite plugin. In production it renders nothing. How to use it [#how-to-use-it] 1. Start the FM MCP daemon locally. 2. Open the FileMaker file you want to develop against. 3. Run the **Connect to MCP** script in that file. It opens a small Web Viewer window that registers the file with FM MCP and proxies script calls. 4. Run your dev server (e.g. `pnpm dev`). From the web app, call FileMaker scripts the same way you would in production: ```ts import { fmFetch } from "@proofkit/webviewer"; const result = await fmFetch("My Script", { id: 123 }); ``` The bridge discovers the connected file via `GET /connectedFiles` on FM MCP, opens a WebSocket to `/ws`, and forwards each script call to FileMaker. The FileMaker **Connect to MCP** script opens a Web Viewer window that the bridge depends on. It must stay open and in **Browse mode** while you develop — closing the window or switching the file to Layout mode silently breaks the bridge. Troubleshooting [#troubleshooting] * **"fmBridge could not reach ..."** — FM MCP is not running or is bound to a different port. Check that the daemon is up and that `fmMcpBaseUrl` matches. * **"fmBridge found no connected FileMaker files"** — A FileMaker file is open but has not registered with FM MCP. Run **Connect to MCP** in that file again. * **Script calls hang or fail at runtime** — The connector Web Viewer was closed or the file was put into Layout mode. Reopen the connector window. --- # fmFetch URL: https://proofkit.proof.sh/docs/webviewer/fmFetch import { DynamicCodeBlock } from "fumadocs-ui/components/dynamic-codeblock"; import { Callout } from "fumadocs-ui/components/callout"; The purpose of the fmFetch function is to call a FileMaker script and get the result of the FileMaker script back to your web application running in a webviewer. If you don't care about the script result, check out the [callFMScript](/docs/webviewer/callFmScript) function instead. To accomplish this, this function wraps the `FileMaker.PerformScript` function injected into the webviewer by FileMaker Pro and assigns each invocation of your fetch with a unique ID. In turn, the FileMaker script that you call must call back into the webviewer with this callback ID and the result of your script. To see a working example of this, download this [demo file](/fmFetch-demo.fmp12). Simple Example [#simple-example] Let's say you have the following in your Javascript code: ```ts title="index.ts" import { fmFetch } from "@proofkit/webviewer"; async function getData() { const result = await fmFetch("GetSimpleResult"); } ``` And the following in your FileMaker script named `GetSimpleResult`: ```FileMaker title="GetSimpleResult" # Required properties Set Variable [ $json ; Value: Get ( ScriptParameter ) ] Set Variable [ $callback ; Value: JSONGetElement ( $json ; "callback" ) ] Set Variable [ $webViewerName ; "web" ] # $result must be an object. Set Variable [ $result ; Value: JSONSetElement ( "" ; [ "hello" ; "world" ; JSONString ] ) ] Set Variable [ $callback ; Value: JSONSetElement ( $callback ; ["result"; $result; JSONObject ]; ["webViewerName"; $webViewerName; JSONString ]) ] Perform Script [ Specified: From list ; "SendCallBack" ; Parameter: $callback ] ``` The `SendCallBack` script comes with the FileMaker addon that you installed with the [ProofKit CLI](/docs/cli), or from the [Demo File](/fmFetch-demo.fmp12). The awaited result of the `fmFetch` call will be: ```json { "hello": "world" } ``` Passing Script Parameters [#passing-script-parameters] A script parameter can be passed to the fmFetch function as a string or JS object. The script parameter will be passed to the FileMaker script as a string. ```ts import { fmFetch } from "@proofkit/webviewer"; async function getData() { const result = await fmFetch("ScriptName", { param1: "value1", param2: "value2", }); } ``` Then simply parse out the script parameter via the data key in your FileMaker script. ```FileMaker title="ScriptName" Set Variable [ $json ; Value: Get ( ScriptParameter ) ] Set Variable [ $callback ; Value: JSONGetElement ( $json ; "callback" ) ] Set Variable [ $data ; Value: JSONGetElement ( $json ; "data" ) ] ``` TypeScript Support [#typescript-support] If you want to directly type the result of your FileMaker script, you can pass a type to the fmFetch function. ```ts type Result = { hello: string; }; async function getData() { const result = await fmFetch("GetSimpleResult"); } ``` The type that you pass here is not validated with the actual FileMaker script result. You may want to consider validating the data that is returned from FileMaker with a runtime validation library such as [zod](https://zod.dev). This technique is most powerful when combined with the Execute FileMaker Data API script step and automatic type generation found in the [@proofkit/fmdapi](/docs/fmdapi) package. --- # Data API Integration URL: https://proofkit.proof.sh/docs/webviewer/fmdapi import { Callout } from "fumadocs-ui/components/callout"; import { Steps, Step } from "fumadocs-ui/components/steps"; import { Accordions, Accordion } from "fumadocs-ui/components/accordion"; We can use the `Execute FileMaker Data API` script step to harness the power of the [@proofkit/fmdapi](/docs/fmdapi) library in our webviewer integration. * ✅ Use the same code and functions as in a browsed-based app * including typegen for a nice auto-complete experience and runtime validation for protection if field names are changed. * ✅ No authentication required (it runs in the process of the logged in user) * ✅ Works in offline FileMaker apps * ✅ Works even if the Data API is disabled on the server Setup [#setup] If you followed the [ProofKit AI build workflow](/docs/ai/build-a-webviewer-app), these steps are already done for you. Install both packages [#install-both-packages] npm pnpm yarn bun ```bash npm install @proofkit/fmdapi @proofkit/webviewer ``` ```bash pnpm add @proofkit/fmdapi @proofkit/webviewer ``` ```bash yarn add @proofkit/fmdapi @proofkit/webviewer ``` ```bash bun add @proofkit/fmdapi @proofkit/webviewer ``` FileMaker Script Installation [#filemaker-script-installation] Copy the `ExecuteDataAPI` and `SendCallback` scripts from the [demo file](/fmdapi-demo.fmp12) to your own FileMaker solution. Initialize the DataAPI client [#initialize-the-dataapi-client] For more details about this step, see the [@proofkit/fmdapi](/docs/fmdapi) documentation. If you're using using [typegen](/docs/fmdapi/typegen), modify your `fmschema.config.mjs` file to include the script name that calls the `Execute FileMaker Data API` script step ```js title="fmschema.config.mjs" export const config = { // ...other config webviewerScriptName: "ExecuteDataApi", }; ``` Then simply run the typegen command to generate the client. If you're manually creating the client, use the webviewer adapter from the `@proofkit/webviewer` package. ```ts title="client.ts" import { DataApi } from "@proofkit/fmdapi"; import { WebViewerAdapter } from "@proofkit/webviewer/adapter"; export const client = DataApi({ adapter: new WebViewerAdapter({ scriptName: "ExecuteDataApi" }), layout: "API_Customers", // put your layout name here }); ``` Repeat this for each layout that you want to interact with. Usage [#usage] Now you can use the DataAPI client just as you would in a browsed-based app! ```ts import { UsersClient } from "./schema/client"; const users = await UsersClient.findOne({ query: { id: "===1234" } }); ``` For examples of all methods, see the [@proofkit/fmdapi](/docs/fmdapi) documentation. --- # Web Viewer Apps URL: https://proofkit.proof.sh/docs/webviewer The hybrid app model and the @proofkit/webviewer bridge. import { Card, Cards } from "fumadocs-ui/components/card"; import { Callout } from "fumadocs-ui/components/callout"; A ProofKit Web Viewer app is a modern web interface running inside a FileMaker Web Viewer. The web layer handles the UI. FileMaker still provides the data, security, scripts, file system access, printing, and deployment environment. This section covers both the conceptual model and the `@proofkit/webviewer` bridge package that connects the web app to FileMaker scripts and data. Start with the [ProofKit AI guide](/docs/ai/getting-started) for the recommended install, build, and deploy path. Use this Web Viewer section when you want to understand the hybrid app model or work directly with the bridge package. Learn why a Web Viewer app can be a practical architecture, not just an escape hatch. See how the agent, MCP server, plug-in, add-on, FileMaker file, and Web Viewer connect. Understand loading, communication, caching, saving, record locking, containers, and printing. Use the bridge to call FileMaker scripts and read data from the web app. The short version [#the-short-version] Think of the Web Viewer as the interface layer and FileMaker as the application platform underneath it. * The user interacts with React UI in the Web Viewer. * The web app calls FileMaker scripts when it needs data or business logic. * Scripts read and write the database with the user's FileMaker permissions. * Scripts can also call external APIs, access files, generate PDFs, and use plug-ins. Start with [Why WebViewers?](/docs/webviewer/why-webviewers) for the concept, then read [Data Access](/docs/webviewer/data-access) when you are designing real screens. --- # Initial Props URL: https://proofkit.proof.sh/docs/webviewer/initial-props Pull bootstrap data from FileMaker into the Web Viewer at startup. import { Callout } from "fumadocs-ui/components/callout"; The **initial props** pattern is how a Web Viewer app gets bootstrap data from FileMaker at startup — things like the current user, the active record ID, or a starting route. Problems you might be solving [#problems-you-might-be-solving] FileMaker and the Web Viewer are separate runtimes with no shared memory. The web app cannot read FileMaker fields or globals directly, and FileMaker cannot safely inject values before the JavaScript has loaded. Initial props bridge that gap. * **Your web app needs to know the current user at startup** — account name, display name, or privilege set so the UI can adapt before the first render. * **You want the Web Viewer to open to a specific screen** depending on which FileMaker layout, record, or button launched it. * **You need the active record ID before the first render** so the app can immediately fetch or display the right data. * **Data you inject into the Web Viewer HTML keeps getting lost** — substitution or script-trigger approaches race against bundle loading and silently fail. If any of these sound familiar, read on. The rest of this page shows the pattern and gives copy-ready examples. Pull, don't push [#pull-dont-push] The Web Viewer asks FileMaker for its initial props. FileMaker does not push them in. Concretely: the Web Viewer calls a FileMaker script via [`fmFetch`](/docs/webviewer/fmFetch) once it has mounted, and uses the returned data to finish bootstrapping. Do **not** seed initial props by: * Substituting values into the HTML / web viewer URL before render. * Calling `FileMaker.PerformJavaScriptInWebViewer` from an `OnLayoutEnter` or `OnRecordLoad` script trigger when the viewer opens. Both paths race against the web app loading. The script step or substitution can fire before your JavaScript bundle has parsed and your handler is attached, and the props are silently lost. The pull direction inverts the timing problem. By the time the Web Viewer makes the `fmFetch` call, it has confirmed three things at once: 1. The JavaScript bundle has loaded and executed. 2. `window.FileMaker` has been injected by Pro / Go and is callable. 3. Any handlers the FileMaker script needs to call back into (via the `SendCallBack` script) are wired up. In the ProofKit Web Viewer template, the `fmFetch` call fires the moment the web code loads — **before** the router mounts and **before** the first route renders. The router then receives the resolved props as part of its context, so the first screen a user sees can already depend on FileMaker state (the signed-in user, the active record, a starting route) without a flash of empty UI or a post-mount re-render. Basic shape [#basic-shape] ```ts title="bootstrap.ts" import { fmFetch } from "@proofkit/webviewer"; import { z } from "zod"; const initialPropsSchema = z.object({ user: z.object({ id: z.string(), name: z.string(), email: z.email(), }), initialRoute: z.string().optional(), }); type InitialProps = z.infer; export async function getInitialProps(): Promise { const result = await fmFetch("GetInitialProps"); return initialPropsSchema.parse(result); } ``` On the FileMaker side, `GetInitialProps` collects whatever the app needs and sends it back through the standard `fmFetch` callback (see [fmFetch](/docs/webviewer/fmFetch) for the script shape). Validate the script result with [zod](https://zod.dev) (or similar). The Web Viewer cannot trust shape inference across the FileMaker boundary. Example: initial route [#example-initial-route] A Web Viewer that uses a client-side router (e.g. TanStack Router with hash history) can be told where to start. Useful when one FileMaker layout hosts a viewer that should land on different screens depending on context. ```ts title="src/router.ts" import { fmFetch } from "@proofkit/webviewer"; import { createHashHistory, createRouter } from "@tanstack/react-router"; import { z } from "zod"; import { routeTree } from "./route-tree"; const initialPropsSchema = z.object({ initialRoute: z.string().optional(), }); const GET_INITIAL_PROPS_SCRIPT = "GetInitialProps"; export async function createAppRouter() { const result = await fmFetch(GET_INITIAL_PROPS_SCRIPT); const { initialRoute } = initialPropsSchema.parse(result); if (initialRoute && !window.location.hash) { window.location.hash = initialRoute; } return createRouter({ history: createHashHistory(), routeTree, }); } ``` ```FileMaker title="GetInitialProps" Set Variable [ $json ; Value: Get ( ScriptParameter ) ] Set Variable [ $callback ; Value: JSONGetElement ( $json ; "callback" ) ] # Pick a starting route based on whatever FileMaker context matters. If [ not IsEmpty ( Customers::id ) ] Set Variable [ $route ; Value: "/customers/" & Customers::id ] Else Set Variable [ $route ; Value: "/" ] End If Set Variable [ $result ; Value: JSONSetElement ( "" ; [ "initialRoute" ; $route ; JSONString ] ) ] Set Variable [ $callback ; Value: JSONSetElement ( $callback ; [ "result" ; $result ; JSONObject ] ; [ "webViewerName" ; "web" ; JSONString ] ) ] Perform Script [ Specified: From list ; "SendCallBack" ; Parameter: $callback ] ``` The check on `window.location.hash` matters: if the user has already navigated inside the viewer, you should not yank them back to the initial route on a refresh. Example: current user [#example-current-user] Hand the app the user identity it needs to render. ```ts title="src/lib/initial-props.ts" import { fmFetch } from "@proofkit/webviewer"; import { z } from "zod"; export const initialPropsSchema = z.object({ user: z.object({ accountName: z.string(), fullName: z.string(), privilegeSet: z.string(), }), }); export type InitialProps = z.infer; export async function fetchInitialProps(): Promise { const result = await fmFetch("GetInitialProps"); return initialPropsSchema.parse(result); } ``` ```FileMaker title="GetInitialProps" Set Variable [ $json ; Value: Get ( ScriptParameter ) ] Set Variable [ $callback ; Value: JSONGetElement ( $json ; "callback" ) ] Set Variable [ $result ; Value: JSONSetElement ( "" ; [ "user.accountName" ; Get ( AccountName ) ; JSONString ] ; [ "user.fullName" ; Get ( UserName ) ; JSONString ] ; [ "user.privilegeSet" ; Get ( AccountPrivilegeSetName ) ; JSONString ] ) ] Set Variable [ $callback ; Value: JSONSetElement ( $callback ; [ "result" ; $result ; JSONObject ] ; [ "webViewerName" ; "web" ; JSONString ] ) ] Perform Script [ Specified: From list ; "SendCallBack" ; Parameter: $callback ] ``` In the app, gate render on the bootstrap: ```tsx title="src/main.tsx" import React from "react"; import ReactDOM from "react-dom/client"; import App from "./app"; import { fetchInitialProps } from "./lib/initial-props"; const propsPromise = fetchInitialProps(); function Boot() { const props = React.use(propsPromise); return ; } ReactDOM.createRoot(document.querySelector("#root")!).render( Loading…}> , ); ``` When initial props are not the right tool [#when-initial-props-are-not-the-right-tool] Initial props are for **bootstrap**. They are fetched once. If a value can change while the viewer is open (the active record, a selected portal row, a setting toggled elsewhere in the file), prefer: * An explicit refresh via [`fmFetch`](/docs/webviewer/fmFetch) triggered by a user action. * A FileMaker-initiated push via `FileMaker.PerformJavaScriptInWebViewer` once you know the viewer is ready — e.g. after the initial-props handshake has completed. --- # @proofkit/webviewer URL: https://proofkit.proof.sh/docs/webviewer/package Use the Web Viewer bridge package directly in custom apps. import { Callout } from "fumadocs-ui/components/callout"; import { Accordion, Accordions } from "fumadocs-ui/components/accordion"; Use this page when you already have a Vite app, Next.js app, custom Web Viewer project, or another web app where you want to use the ProofKit bridge directly. If you are new to ProofKit and want the recommended path from install to deployed FileMaker app, start with the [ProofKit AI guide](/docs/ai/getting-started). What this package does [#what-this-package-does] `@proofkit/webviewer` makes it easier to work with FileMaker scripts and data from a custom Web Viewer integration. It runs in a FileMaker Web Viewer and lets your app interact with your FileMaker solution through local scripts. The happy path starts with [ProofKit AI](/docs/ai/getting-started). Come back here when a guide points you to lower-level Web Viewer bridge details, or when you are wiring the package into an existing app yourself. This is a **client-side** package, meant to run specifically in a FileMaker Web Viewer, but it can still be used in a hosted web app, such as Next.js. However, it will cause errors if loaded in a standard browser. For more information about deployment strategies, see the [Deployment Methods](/docs/webviewer/deployment-methods) guide. For local development outside FileMaker, use [`fmBridge`](/docs/webviewer/fm-bridge). It supports: * Vite through `@proofkit/webviewer/vite-plugins` * Next.js App Router through `` * Next.js Pages Router through `getFmBridgeScriptProps()` plus `` For web-based applications where you're looking to interact with the Data API using a network request, check out the [@proofkit/fmdapi](/docs/fmdapi) package instead. Add it to an existing app [#add-it-to-an-existing-app] The [ProofKit AI workflow](/docs/ai/build-a-webviewer-app) can scaffold a full Web Viewer project and install the FileMaker add-on that provides the necessary layouts, scripts, and custom functions. Use that path when you want ProofKit to create the project structure for you. When you scaffold a Web Viewer project with `proofkit init`, ProofKit downloads the latest FileMaker add-on from the ProofKit CDN and opens it in FileMaker automatically; you still need to add the add-on into your FileMaker file. For manual installation, follow the steps below. {" "} This demo file is a very simplified example. To see more features, use the [ProofKit AI workflow](/docs/ai/build-a-webviewer-app) to build a new app or scaffold one with `proofkit init`, then install the FileMaker add-on. Use your preferred package manager to install the package. npm pnpm yarn bun ```bash npm install @proofkit/webviewer ``` ```bash pnpm add @proofkit/webviewer ``` ```bash yarn add @proofkit/webviewer ``` ```bash bun add @proofkit/webviewer ``` FileMaker File Setup [#filemaker-file-setup] Download this [Demo FileMaker file](/fmFetch-demo.fmp12) and copy the scripts folder named `fm-webviewer-fetch` into your own FileMaker solution. Demo file credentials: `admin` / `admin` Related reference [#related-reference] * [`fmFetch`](/docs/webviewer/fmFetch) wraps FileMaker script calls that need a result back in the Web Viewer. * [`callFMScript`](/docs/webviewer/callFmScript) calls a FileMaker script when you do not need a result. * [`fmBridge`](/docs/webviewer/fm-bridge) lets a local Vite or Next.js dev server talk to a real connected FileMaker file. * [Data Access](/docs/webviewer/data-access) explains the generated FileMaker data path used by ProofKit Web Viewer apps. --- # Platform Notes URL: https://proofkit.proof.sh/docs/webviewer/platform-notes Runtime notes for FileMaker Pro, FileMaker Go, and WebDirect. ProofKit Web Viewer apps are built during development and then deployed into FileMaker. After deployment, the runtime environment is FileMaker. FileMaker Pro [#filemaker-pro] FileMaker Pro is required for the agentic development workflow. Your file must be open in FileMaker Pro so ProofKit can connect through the local bridge. Deployed Web Viewer apps can also run in FileMaker Pro on macOS and Windows. FileMaker Go [#filemaker-go] After deployment, Web Viewer apps can run in FileMaker Go. Test mobile-specific layouts, viewport behavior, and any script behavior that depends on platform capabilities. WebDirect [#webdirect] Deployed Web Viewer apps can run in WebDirect, but browser refresh and session behavior need special care. Avoid designs that assume a user can freely refresh a WebDirect window without affecting their FileMaker session. End users [#end-users] End users do not need ProofKit installed. They need the FileMaker runtime where the Web Viewer app is deployed. Development versus runtime [#development-versus-runtime] | Requirement | Development | Runtime | | -------------------------- | ------------ | --------- | | ProofKit installer | Yes | No | | FileMaker Pro | Yes | Optional | | Node.js | Yes | No | | MCP-compatible agent | Yes | No | | Deployed Web Viewer bundle | Created here | Runs here | --- # Runtime Under the Hood URL: https://proofkit.proof.sh/docs/webviewer/runtime-under-the-hood What happens when a user opens and interacts with a ProofKit hybrid app. This page explains the runtime behavior of a deployed ProofKit Web Viewer app: loading, communication, data fetching, caching, saving, and FileMaker-specific behavior. Loading the app [#loading-the-app] When a user opens a FileMaker layout with a ProofKit Web Viewer, the Web Viewer loads the deployed HTML and JavaScript bundle from the FileMaker file. Initial props [#initial-props] Many apps start by calling a FileMaker script before rendering the full UI. That script can return user context, configuration, permissions, or startup data the web app needs. This is optional, but it is a good pattern when the app needs FileMaker context before showing a meaningful screen. Communication bridge [#communication-bridge] The Web Viewer and FileMaker are separate runtimes. They communicate by passing JSON through FileMaker's script bridge: * The web app calls FileMaker. * A FileMaker script performs work. * FileMaker returns structured data to the Web Viewer. Under the hood, that bridge uses two FileMaker features: * JavaScript in the Web Viewer can call `FileMaker.PerformScriptWithOption(script, parameter, option)` to ask FileMaker to run a script. Claris documents this on [Scripting with JavaScript in web viewers](https://help.claris.com/en/pro-help/content/scripting-javascript-in-web-viewers.html). * FileMaker can call back into the Web Viewer with the [Perform JavaScript in Web Viewer](https://help.claris.com/en/pro-help/content/perform-javascript-in-web-viewer.html) script step. Those APIs are asynchronous and string-based, so the raw version usually involves passing JSON, tracking callbacks, and deciding how a currently running FileMaker script should behave when JavaScript starts another one. ProofKit libraries hide most of that callback plumbing so app code can use modern async patterns. [`fmFetch`](/docs/webviewer/fmFetch) wraps the Web Viewer-to-FileMaker call and callback cycle. [`@proofkit/fmdapi`](/docs/fmdapi) and [`@proofkit/typegen`](/docs/typegen) build on FileMaker's data APIs and layout metadata so generated clients can read and write strongly typed FileMaker data without every app reimplementing the bridge details. Caching and reactivity [#caching-and-reactivity] ProofKit apps use TanStack Query for server state. In this context, server state means FileMaker state: the data in your FileMaker tables and the behavior exposed through your FileMaker scripts. You can think of those scripts and databases as the server-side piece, even when the app is running in a FileMaker file that is not hosted on a server. TanStack Query is a React data-fetching library that handles caching, background refreshes, request deduping, and update synchronization for data that lives outside the browser. See the [TanStack Query overview](https://tanstack.com/query/latest/docs/framework/react/overview) for more detail. Data can be cached locally in the browser, refreshed in the background, and invalidated after writes so the UI stays responsive without manually reloading every screen. Saving data [#saving-data] Web Viewer apps usually use explicit save and cancel actions. They do not automatically commit records when a user exits a field the way native FileMaker layouts can. When saves need business logic, validation, or transactional behavior, send the payload to a FileMaker script and let the script perform the write. Record locking [#record-locking] Typing into a Web Viewer form does not hold a FileMaker record lock. This is normal web app behavior, but it is different from editing directly in a FileMaker field. Common strategies include: * Check modification counts before saving. * Use script-mediated saves for transaction-sensitive changes. * Alert the user when a record changed since it was loaded. Container data [#container-data] Data passed through the Web Viewer bridge is JSON. Container data usually needs to be Base64-encoded before it is included in a JSON payload. Printing and PDFs [#printing-and-pdfs] For print or PDF workflows, the web app can generate an image or document payload, pass it to FileMaker, and let FileMaker use its native printing or Save as PDF capabilities. Next step [#next-step] Read [Data Access](/docs/webviewer/data-access) for practical layout and Execute Data API guidance. --- # Troubleshooting URL: https://proofkit.proof.sh/docs/webviewer/troubleshooting The fmFetch promise is never resolved / callback function is never called / "timed out" error [#the-fmfetch-promise-is-never-resolved--callback-function-is-never-called--timed-out-error] This happens if the result of your FileMaker script is unable to get it back to the web viewer for one of many reasons: * The `SendCallback` script is not called at the end of your FileMaker script. * The `SendCallback` script is called when the user is no longer on the layout that contains the webviewer. * This most often happens if the user has multiple windows open, or if you are using Perform Script on Server with Callback and the callback resolves in another window, but can also happen if your script simply navigates away and does not return to the webviewer layout before calling `SendCallback`. * The `SendCallback` script is called with the wrong webviewer name / your webviewer object does not have a name If the `SendCallback` script is not called, or called with the wrong webviewer name, FileMaker cannot reach back into the JavaScript code to complete the loop. Make sure that you are not exiting/halting the script early or leaving the layout that contains the webviewer. The FileMaker script does not run. [#the-filemaker-script-does-not-run] Verify this by opening the script debugger before performing the action in your webviewer that should trigger the script; you should see your script begin executing. If you try to call a script that does not exist in your FileMaker solution, you will see a FileMaker error dialog. If you don't see that dialog, make sure that the Allow JavaScript to perform FileMaker scripts option is enabled in the webviewer configuration; it is disabled by default. Error: 'window.FileMaker' was not available at the time this function was called. [#error-windowfilemaker-was-not-available-at-the-time-this-function-was-called] FileMaker injects neccesary code into the webviewer to enable these interactions, but it is not available immediately when the webviewer first loads. There are many techniques to handle this, but essentially you need to introduce a delay before you use these functions if you run into this error. --- # Why WebViewers? URL: https://proofkit.proof.sh/docs/webviewer/why-webviewers Why modern web UI inside FileMaker is a strong architecture. A Web Viewer app lets you replace a FileMaker layout with modern web UI while keeping the FileMaker capabilities that already make the system valuable. What you gain [#what-you-gain] * **UI freedom**: use modern components, charts, grids, calendars, drag-and-drop, and responsive layouts. * **Inherited security**: keep FileMaker accounts, privilege sets, and data access rules. * **Scripts as a backend**: run business logic in FileMaker instead of exposing secrets in browser code. * **CORS-free requests**: let FileMaker scripts call external APIs when the browser cannot. * **File system access**: use FileMaker and plug-ins for local machine capabilities. * **Printing and PDFs**: keep using FileMaker's print and PDF workflows. * **Staged adoption**: replace one workflow before you rewrite anything else. A useful analogy [#a-useful-analogy] Slack, VS Code, and Figma all use web UI in a native shell. A FileMaker hybrid app uses the same broad idea, but the shell includes a multi-user database, security model, scripting engine, and deployment path. What stays FileMaker [#what-stays-filemaker] The Web Viewer does not replace your whole solution. Your users, data, security, scripts, and deployment model can remain FileMaker-native while selected screens become modern web experiences. Next step [#next-step] Read [Architecture](/docs/webviewer/architecture) to see how the pieces connect.