Data API best practices: sessions, scripts, and rate limits

Expert

Design reliable Data API integrations by reusing tokens, handling expiry gracefully, writing clean API-facing scripts in FileMaker, and staying within server rate limits.

What you'll learn

How to store and reuse a session token to avoid unnecessary login overhead
How to design FileMaker API scripts with a clean, consistent interface
What rate limiting looks like and how to avoid hitting it

The difference between a brittle Data API integration and a production-grade one comes down to session management, error recovery design, and keeping the FileMaker server healthy under load.

1/3

Store and reuse your session token

Each login creates a new server-side session. Authenticating on every call wastes server resources and slows your integration. Store the token in a global variable or a dedicated globals table and reuse it until it expires.

FileMaker Script

# Login script — call once, store token globally
If [ IsEmpty ( $$FM_API_TOKEN ) ]
  Insert from URL [
    Select ; No dialog ; Target: $loginResponse ;
    URL: $baseURL & "/sessions" ;
    cURL options: "-X POST " &
                  "-H \"Content-Type: application/json\" " &
                  "-H \"Authorization: Basic " & Base64Encode ( $creds ) & "\""
  ]
  Set Variable [ $error ; Value: Get ( LastError ) ]
  If [ $error ≠ 0 ]
    Exit Script [ Result: "error:login:" & $error ]
  End If
  Set Variable [ $$FM_API_TOKEN ; Value:
    JSONGetElement ( $loginResponse ; "response.token" )
  ]
End If

Using the metadata endpoint to inspect layout fields Back to Data API