Overview and exports

@adt/fmdapi is the single library your Web Viewer app uses to talk to FileMaker. It bundles three things in one package:

  • A Data API client (DataApi, methods like find, get, list, create, update, delete) with runtime validation of field names.

  • A Web Viewer bridge adapter (WebViewerAdapter) that routes those calls through a FileMaker script instead of a network request, plus fmFetch/callFMScript for calling FileMaker scripts directly and a command registry for the FileMaker-to-JavaScript direction.

  • A set of agent skills that teach your coding agent how to use all of the above correctly.

Note  Vendored, not installed Agentic Development Toolkit (ADT) never has you add @adt/fmdapi as a registry dependency. When you create your first Web Viewer app with adt app add, the library is copied into the project at vendor/@adt/fmdapi — a single shared copy per project, used by every app in it.

Because it's vendored, pnpm install won't update it. Ask your agent to bring it up to the current build. It's part of the generated codebase, not something pulled from a package registry — so it shows up in your diffs and is safe to read.

The export surface

The package has a root entry point plus four subpath exports, matching vendor/@adt/fmdapi/package.json in your project:

Import path What it exports
@adt/fmdapi Everything below, re-exported from one place: DataApi (default export too), WebViewerAdapter, fmFetch, callFMScript, FMScriptOption, globalSettings, FileMakerError, the command-registry functions, and shared types (GetResponse, CreateResponse, FieldMetaData, etc).
@adt/fmdapi/adapter WebViewerAdapter and its option/type surface (WebViewerAdapterOptions, ExecuteScriptOptions) on its own, for code that needs the adapter without pulling in the rest.
@adt/fmdapi/commands The Web Viewer command registry: initWebViewerCommands, registerWebViewerCommand, unregisterWebViewerCommand, getWebViewerCommandRegistry, and their types.
@adt/fmdapi/react useWebViewerCommand, a React hook wrapper around the command registry.
@adt/fmdapi/vite (also aliased as @adt/fmdapi/vite-plugins) fmBridge(), the Vite dev plugin that forwards Data API calls to a real connected FileMaker file during local development.

The three bundled skills

Every vendored copy of @adt/fmdapi ships its skills alongside the code, so your coding agent picks them up automatically:

  • type-safe-data-api — reading, finding, creating, updating, and deleting records with the generated typegen client, DataApi, and WebViewerAdapter; when to reach for TanStack Query; common mistakes like treating get() as returning a single record instead of an array.

  • webviewer-runtime — using the package inside the actual Web Viewer/WebDirect runtime: fmBridge() for local dev forwarding, registering Web Viewer commands, and loading initial props before the first route.

  • script-actions — calling FileMaker scripts from JavaScript with fmFetch and callFMScript, the script-parameter envelope FileMaker scripts must read from, and why multi-record transactions belong in a FileMaker script rather than in Data API CRUD calls.

When you touch the library directly

Most of the time you won't write DataApi(...) or new WebViewerAdapter(...) yourself. Configuring adt.config.json and running Typegen generates a client per layout, already wired to the right adapter and script name. See Generate types with Typegen for that workflow.

Reach for the library's exports directly when:

  • You need to call a FileMaker script that isn't a Data API CRUD operation — a transaction, a multi-record update, a navigation action. Use fmFetch or callFMScript from the root export.

  • FileMaker needs to call into your Web Viewer — register a handler with registerWebViewerCommand or useWebViewerCommand.

  • You're configuring local dev forwarding in vite.config.ts with fmBridge().

  • You're building a one-off client by hand instead of through typegen (rare — prefer the generated client so field names stay validated against the layout).

Explore the reference