filesoft.Discuss a project
← Practical FileMaker guides

PRACTICAL FILEMAKER GUIDES

FileMaker error 401: an empty find or an authentication problem?

Identify which system produced 401 before changing credentials or rewriting your search.

First identify who returned the number

You see 401 in a log and assume the password is wrong. That can send you down the wrong path. An HTTP response status and a FileMaker error code use separate numbering systems. Preserve the source of the number whenever you log it.

Where 401 appearsWhat to investigate first
Get ( LastError ) after a FileMaker findThe find returned no matching records
A FileMaker messages entry in an API JSON responseThe FileMaker operation and its criteria
The HTTP response status lineAuthentication for the HTTP resource

The Claris error list defines FileMaker 401 as no records matching the request. HTTP 401 has a different meaning. Do not rename every numeric code “HTTP error” in your logs.

1. Capture the failure at its source

For a native find, capture Get ( LastError ) immediately after Perform Find, before another operation changes the error state. Store it in a local variable. Also preserve the layout name and a safe description of the search. The Get ( LastError ) reference explains why timing matters.

For an HTTP request, keep three separate observations: transport success or failure, HTTP response status, and the application response body. A proxy may return an HTML error page instead of FileMaker JSON. Do not run JSON extraction blindly and then mistake that parsing failure for the original error.

Observation record
Operation: find a practice contact
Source: FileMaker messages array
Code: 401
HTTP status: record separately if this was REST
Layout: Contacts API
Expected: one known practice contact
Actual: no matching records

2. Investigate the no-match branch

  1. Use the Error Troubleshooter with code 401, source FileMaker error code, and context Find request.
  2. In your practice file, search for one ContactID you can see on the intended layout. If that fails, check the layout’s table context and the actual stored value.
  3. Remove additional criteria temporarily. Add each one back until the expected record disappears.
  4. Check exact-match operators, blank values, date interpretation and omit requests. Two criteria inside the same request must both be satisfied.
  5. Repeat a deliberately impossible find and confirm your interface shows a clear empty result.

An empty result is sometimes expected. A “find overdue tasks” button can reasonably report that none exist. A “load the contact just selected” action may treat the same outcome as a problem to investigate. Handle the result according to the workflow; do not suppress every 401 without checking the operation.

Browser tool: the FileMaker 401 checklist in Find request context.
Browser tool: the FileMaker 401 checklist in Find request context. Open the image for a larger view.

3. Investigate the HTTP branch separately

If the HTTP status is 401, inspect the response’s authentication information and the service documentation. For a FileMaker Data API integration, confirm you are addressing the intended host and database and using the correct authorized session token. Keep tokens out of screenshots and shared logs.

  1. Check whether the request reached the expected service rather than a proxy, gateway or different URL.
  2. Check the authorization header’s presence and format without publishing its value.
  3. Follow the service’s documented session renewal process when the session is no longer valid.
  4. Retry in a controlled way, retaining the original failure and the new result. Avoid an unlimited retry loop.

Changing city or status criteria will not repair an HTTP authentication failure. Likewise, replacing a valid password will not create a contact that does not match a FileMaker find.

4. Use the lookup as a starting checklist

The Filesoft tool covers a curated set of common FileMaker codes. Choose the context as well as the number, then copy the checklist into your investigation notes. Unknown codes should be checked against the complete Claris reference; absence from this tool does not mean a code is invalid.

The HTTP option explains the namespace distinction. It is not a complete HTTP-status troubleshooter. For a non-FileMaker service, consult that service’s documentation before applying FileMaker-specific advice.

5. Verify both success and failure

CheckEvidence to keep
Known matching contactExpected ContactID returned
Impossible practice criterionClear no-match outcome without stale contact details
HTTP authentication failure, if relevantStatus identified separately; no success message
Recovery after correctionOne successful result, without uncontrolled repeated requests

Do not leave the previous customer’s details visible when a new search returns no match. Clear or explicitly label the stale result. Finish the investigation with the failing operation, the change you made, and both test outcomes. “It worked after a retry” is weaker evidence than knowing which condition changed.

References

Use a practice copy and verify the result in your FileMaker version. Browser screenshots demonstrate the tool; they do not establish native FileMaker testing.