Troubleshoot FileMaker API requests

“The API did not work” can describe several different problems: no connection, a rejected request, an unexpected response or a local save that failed afterward. Investigate those stages separately so you change the right thing.

Use this checklist with a controlled endpoint and a copy of your FileMaker file. It assumes an Insert from URL request using cURL options and response variables. FileMaker Pro is required and sold separately.

1. Preserve the first useful evidence.

Use Set Error Capture [On] where your script handles errors itself. Immediately after Insert from URL, capture the code and detail together in one Set Variable calculation:

FileMaker calculation

Let ( [
    code = Get ( LastError ) ;
    detail = Get ( LastErrorDetail )
] ;
    JSONSetElement ( "{}" ;
        [ "code" ; code ; JSONNumber ] ;
        [ "detail" ; detail ; JSONString ]
    )
)

Store that result in a diagnostic variable before running other steps. Successful intervening steps can replace the last error. Error capture suppresses automatic alerts; it does not repair the request.

This example uses the current Get ( LastErrorDetail ) function name. Check compatibility with your installed version when adapting an older file. Enable response-header capture in the cURL builder too, and clear the response targets before each attempt.

2. Identify the failing stage.

No usable HTTP response: Inspect the FileMaker error and detail. Check the hostname, connectivity, timeout and certificate chain. Keep certificate verification enabled.
HTTP response reports failure: Read the final status and the service’s error body. A response containing JSON is not necessarily a successful result.
HTTP success, wrong application result: Compare the body with the API contract. Check required keys, pagination and any application-level error or pending status.
Remote success, local failure: Inspect your FileMaker mapping, permissions, record locks and commit result. Repeating the HTTP request may duplicate work.

Do not use a zero FileMaker error code as your only success condition. The supported cURL options, including --show-error, affect error reporting. Inspect captured HTTP status and the expected body independently.

3. Use the status to narrow the search.

400 or 422: compare required fields, types and body structure with the API’s validation message.
401: check whether credentials are present, valid and expired.
403: check scopes, account permissions and resource access.
404: check the endpoint path, API version and resource ID.
429: review rate limits and the service’s retry instructions, including Retry-After when present.
5xx: retain the request ID and consult the service status or support guidance.

These are diagnostic starting points; an individual API may use statuses differently or intentionally conceal resource existence. Follow its documented response contract. A captured header stream may contain multiple header blocks, so do not assume the first status line is the final response.

4. Change one thing at a time.

Compare a failing request with a known-good sandbox example. Check method, URL, parameter encoding, authentication, content type and body independently. Keep a small fictional body while diagnosing; add optional fields only after the minimum request works.

Use the JSON formatter on a redacted response to inspect its structure. Use the cURL builder to review quoting and variable references. Neither browser tool can validate your runtime credentials, execute the request or confirm the remote service’s behavior.

For timeouts, establish whether the service completed the operation before retrying. Automated retries need limits and must fit the operation. A create request is particularly sensitive to duplicates; follow the service’s idempotency or reconciliation mechanism.

5. Keep a useful, limited diagnostic record.

Diagnostic record template

Time: 2026-10-08T09:15:00Z
Operation: create test contact
Method/path: POST /contacts
FileMaker error: captured code and sanitized detail
Final HTTP status: captured value, if available
Request ID: provider correlation ID, if supplied
Outcome: rejected / confirmed / uncertain
Body summary: missing required name (fictional example)

Exclude Authorization headers, tokens, passwords and customer payloads. Record a sanitized route rather than a full URL containing secrets. Limit access and retention for diagnostic logs.

Finish by repeating the original case and a failure case. Confirm that the interface distinguishes success, rejection and an uncertain outcome, and that no failure path marks a record as successfully sent.

PUT IT INTO PRACTICE

Try it with Filesoft.

Open the cURL builder

Want a guided learning path? Explore the free FileMaker courses.

Continue reading

Reference: Get ( LastError ) · Get ( LastErrorDetail ) · Set Error Capture · Supported cURL options. Examples are learning aids; check them in your own FileMaker working copy.

Troubleshoot FileMaker API requests.