When to use this endpoint

Use only to reproduce the legacy fname lookup. This endpoint returns a numeric record ID or zero, not a boolean file-system existence check.

Authentication and permissions

Normal requests authenticate with signed API-key fields or a logged-in CRM session. This handler explicitly requires login; CRM2 Files View is not an additional requirement here.

UserFile routes are outside the dispatcher’s File/Files TeamAccess object mapping. They require login where implemented and enforce the tenant rules described here, but do not call File_readGuard or apply the CRM2 Files View check. Do not treat a successful path read as proof of a file-record visibility decision.

Parameters

ParameterTypeRequiredDescription
fnameNonempty stringYesThe query compares files.url to + "/" + the supplied fname. It does not look up filename or file ID. Pass exactly the key expected by that legacy record format; this differs from File_getByUrl, which compares the unprefixed tenant-relative url.

Example request

$id = FM_api('UserFile_exists', ['fname'=>'files/0/1042/abc123']);

Example response

0

Errors and unusual responses

ResponseCondition
{"error":"not logged in"}No authenticated tenant context is available. Invalid signed credentials can be rejected by the dispatcher before the handler runs.
{"error": "missing or invalid parameter: fname"}fname is missing/blank or PHP-falsy, including "0".

Legacy application errors may be returned with HTTP 200. Check the decoded response for error, not only the HTTP status.

Behaviour and edge cases

  • The successful wire response is a JSON integer: matching file-record ID, otherwise 0. It is not {ok:1}, a filename, content or an array.
  • The query has no deleted-row predicate or explicit order and does not call the storage library. A metadata match proves neither live visibility nor available bytes; a missing metadata match does not prove that a backend object is absent.
  • Most File_upload results save files/// without a tenant prefix in files.url. This endpoint prepends the tenant, so passing that ordinary relative URL is not equivalent to File_getByUrl and can return 0 for a downloadable file.

Side effects

  • Metadata query only; no storage download, access-time update, re-upload command or content hydration.

See it in Fieldmotion

CRM1

CRM1 User profiles, Asset/Job photos and report-design images construct /f//... links. The current direct JavaScript callers do not name this RPC explicitly; ordinary file tables generally use File_get.

CRM2

CRM2 User profiles, photos, Job forms, maps and report designers construct /f//... image links. Current imageSetUrl also uses File_getByUrl with base64=1. A path-link consumer is not proof that this exact RPC was called; inspect the actual request.

Related endpoints