FileMaker Server dispatch fails when using FQDN after SSL certificate update

Question: Why did the Klai App report “There was an error dispatching to the business file from the helper file” after a FileMaker Server SSL certificate update, despite restoring databases and the server?

Answer: The issue was traced to a likely bug in FileMaker Server 26.02. The dispatch script failed when the FQDN was used in the business file’s Manage External Data Sources configuration, but succeeded when the FQDN was removed or replaced with the appropriate non-FQDN server reference. The behavior appeared after the SSL certificate change and was escalated to Claris.


Original Slack Thread

User U06LGNXENSY: *Database not accessible via Klai App:*

On 8/27/2026 my IT department pushed out an ssl certificate update to our dev FileMaker server. Soon after, I received a message in the client that the server is shutting down and to close the open databases. After reopening the databases with my client, I was no longer able to access the Klai website that I was actively working on prior to the incident.

Here are some of the troubleshooting steps I took:

1. I cleared the cache for the site in question, issue continued.
2. We rebooted the dev FileMaker server, issue continued.
3. Further troubleshooting revealed the infamous error "There was an error dispatching to the business file from the helperfile error: 0 Possible Causes Incorrect /broken External data source Incorrect credentials in the business file (are data api / xml privs enabled?)"
4. Since nothing else was changed (IE: the user or password or the scripts located in "Hooks - Developer - Transmitter- CONFIGURE HERE" I decided to perform a recover on the business file.
5. I replaced the original database with the recovered file, issue continued.
6. I performed a recover on the helper file and replaced the original with the recovered file, issue continued.
7. My IT restored the entire server from a snapshot back up, issue continued.
I am at a loss now as to what we should look at next. I would really appreciate some direction to get this issue resolved.
User UBBJX2EHM: when they restored is it using the new cert?
User UBBJX2EHM: Have you pinged the XML |  DataAPI and evaluated the cert?
User UBBJX2EHM: Have you run the simple server test from the /servers area in KS to see what it can see?
User U06LGNXENSY: Checking on first question... as far as seeing server under "Servers", yes, it shows the dbs, and I can see valid cert for servr
User U06LGNXENSY: yes, restore was using new cert
User U06LGNXENSY: <@UBBJX2EHM> - sorry any other thoughts? I've been dealing with this issue for over 5 hours now :disappointed:
User UBBJX2EHM: Understood but as you noted somethign changed on your end, not us.

I would google al ssl testing site to see if it really is. Also make sure correct gateways are enabled.

In your journey of troble shooting did you change *anything* else as experiments? Ofen that happens and doesnt get reverted
User UBBJX2EHM: And to confirm, you are not seeing any record hit the helper file?
User U06LGNXENSY: no, I am getting the helper file record WITH that error in the response
User UBBJX2EHM: Does the FMS address produce the FMsplash page (from outside network?
User UBBJX2EHM: If you are seeing a response in the helper the record must be created no??
User U06LGNXENSY: <@UBBJX2EHM> If you are interested, I believe we identified a bug in FMS 26.02 that I have escalated to Claris. If you use the FQDN in the "Manage External Data Sources" to run the "dispatch" script in our business file, it fails. If you don't use the fqdn, it is successful. Odd that it was working after the upgrade, but broke when IT pushed out a new SSL cert.
User UBBJX2EHM: ok thats interesting, has tat been prought up in the community or forums?
User UBBJX2EHM: Glad you got to the bottom of it !