FileMaker JSON Functions Every Developer Should Know

FileMaker JSON functions are now part of everyday development. They carry script parameters, preserve state between layouts, build Data API payloads, and make integrations easier to reason about than long return-delimited strings. The hard part is not remembering that JSONSetElement exists. It is keeping types, paths, missing keys, and error handling predictable as the payload grows.

This guide focuses on the functions and habits that prevent the most common JSON failures in FileMaker.

Start with JSONSetElement, but set the type deliberately

JSONSetElement creates or changes an element at a path:

JSONSetElement ( "{}" ;
  [ "customer.id" ; Customer::PrimaryKey ; JSONString ] ;
  [ "customer.name" ; Customer::Name ; JSONString ] ;
  [ "invoice.total" ; Invoice::Total ; JSONNumber ] ;
  [ "invoice.paid" ; Invoice::Paid ; JSONBoolean ]
)

The fourth argument matters. A number stored as JSONString becomes "125.50" instead of 125.5. A Boolean stored as text becomes "true" instead of true. Those values may look reasonable in FileMaker’s Data Viewer and still fail an external API contract.

Use the named constants—JSONString, JSONNumber, JSONObject, JSONArray, JSONBoolean, JSONNull, and JSONRaw—instead of their numeric equivalents. The calculation becomes self-explanatory, and a later developer does not have to remember what type 2 means.

Use JSONRaw only when the value is already valid JSON and you intend to insert it without quoting. If you pass ordinary text through JSONRaw, FileMaker may interpret it differently than you expect. For nested objects, build and validate the child object first, then add it as JSONObject.

Read values with JSONGetElement

JSONGetElement retrieves the value at a JSON path:

Let ( [
  payload = Get ( ScriptParameter ) ;
  customerId = JSONGetElement ( payload ; "customer.id" ) ;
  total = JSONGetElement ( payload ; "invoice.total" )
] ;
  // continue only after validation
)

The function is simple; the ambiguity is not. A missing key, a JSON null, an empty string, and a numeric zero can all lead to weak tests if you check only whether the returned value is empty.

When a value is required, inspect its type as well as its value. JSONGetElementType lets you distinguish strings, numbers, objects, arrays, Booleans, null values, and invalid JSON. That is especially useful at the boundary of a script: validate the parameter once before downstream steps assume it is safe.

If you are reviewing a long parameter contract, paste the calculation into FMDojo Code Chat and ask it to list every JSON path the script reads and writes. With an active Snapshot, you can also compare those paths against real field names instead of reviewing the payload in isolation.

Use JSONListKeys to inspect unknown objects

When an API changes or a script receives a flexible object, JSONListKeys is a useful diagnostic tool:

JSONListKeys ( $response ; "" )

At the root of an object, it returns the available keys. At an array path, it returns the indexes. This makes it useful for logging an unexpected response without immediately dumping every value.

JSONListValues is different: it returns the values at the selected path. That can be convenient for a simple array of strings, but it is a poor substitute for deliberate array traversal when the elements are objects. Once order and nested fields matter, loop over array indexes and retrieve exact paths.

For example:

Set Variable [ $count ; Value: ValueCount ( JSONListKeys ( $json ; "items" ) ) ]
Set Variable [ $i ; Value: 0 ]
Loop
  Exit Loop If [ $i ≥ $count ]
  Set Variable [ $id ; Value: JSONGetElement ( $json ; "items[" & $i & "].id" ) ]
  # Validate and process $id
  Set Variable [ $i ; Value: $i + 1 ]
End Loop

That loop exposes the contract. It also gives you a clear place to reject or log a malformed item.

Format JSON for people, not transport

JSONFormatElements makes compact JSON readable:

JSONFormatElements ( $payload )

Use it in the Data Viewer, a debug field, or a controlled log. Do not assume formatted JSON is better for transport; APIs do not need the extra whitespace, and a formatted copy can obscure which exact bytes were signed or hashed.

FMDojo’s Code Editor is useful here because you can keep the FileMaker calculation beside a formatted sample payload. Review the shape in the editor, then move only the calculation back to FileMaker. If the JSON contains field names, activate the relevant Snapshot so the review is grounded in the real schema.

Be careful with production logging. JSON payloads often contain names, email addresses, tokens, or record data. Log the status, request ID, endpoint name, and safe structural details. Redact credentials and personal data before storing the payload.

Remove elements instead of rebuilding everything

JSONDeleteElement removes one or more paths. It is useful when a shared base payload contains optional values:

Let ( [
  payload = JSONSetElement ( "{}" ;
    [ "email" ; Contact::Email ; JSONString ] ;
    [ "phone" ; Contact::Phone ; JSONString ]
  ) ;
  result = If (
    IsEmpty ( Contact::Phone ) ;
    JSONDeleteElement ( payload ; "phone" ) ;
    payload
  )
] ;
  result
)

Deleting an absent optional property is often safer than sending an empty string. Many APIs distinguish “do not change this field” from “set this field to empty.”

The same rule applies when you update an existing object: change only the paths you own. Rebuilding the whole object from a partial FileMaker context can silently discard properties added by another system.

Validate at every boundary

A reliable JSON workflow has three checkpoints:

1. Validate the incoming JSON and required paths before the script changes records.
2. Build outgoing JSON with deliberate types and inspect the final structure.
3. Capture the API status and response before assuming the write succeeded.

Do not bury all three in one giant calculation. Use a Let block or small custom functions for calculation-only work, and use script steps when the process needs branching, logging, retries, or record changes.

For an integration script, FMDojo can help at each checkpoint. Use Code Chat to review the FileMaker calculation, a Snapshot to verify referenced fields and scripts, and Flows when the end goal is a saved automation with visible run history rather than an opaque one-off request.

The official Claris JSONSetElement reference is worth keeping nearby for type behavior. The habit that matters most is simple: treat JSON as a typed contract, not just formatted text.

What is new in FM Dojo related to this

FMDojo’s Code Editor and Code Chat can review FileMaker JSON calculations beside the active Snapshot, so field and script names come from the real solution. Flows provide a visible place to build and review repeatable integrations. Start in Code for a calculation review or Snapshots when the payload depends on the current schema.