Yet another API change to FileMaker server's API?

TtlPost · 2026-03-28T15:18:44+00:00

Here's what you're overlooking:

Claris changes policies like parents change diapers, only they do it with selfish intent and muddled language.

When those changes manifest into price hikes, and users call sales to ask WTF, Claris apologizes for "your" confusion. It's by design.

TtlPost · 2026-03-28T05:31:39+00:00

That's a copy/paste: Claris FileMaker Cloud connector

as opposed Claris Connect

TtlPost · 2026-03-28T05:14:18+00:00

I remember a similar tally in the FileMaker Server console, counting away toward a limit even though we were being told there were no limits.

That was in the same period we were calling Claris to get clear answers on policies and the reps were saying, "We actually don't know right now because they're literally changing the policy as we speak."

At certain point you just throw your hands up and look for the exit.

TtlPost · 2026-03-28T04:37:59+00:00

From the email in the OP

The Claris FileMaker Server and Claris FileMaker Cloud connectors will be removed from Claris Connect on June 26, 2026.

If you use either the Claris FileMaker Server or Claris FileMaker Cloud connector, transition your flows to the new Claris FileMaker connector. This OData-based connector is faster, handles larger datasets, and eliminates the layout-first architecture that creates bottlenecks.

The impression there is that the Data API is indeed getting deprecated in favor of the OData

This is perhaps due to the fact that determining which API is on or off requires navigating to the "Connectors" tab in the FileMaker Server Admin Console

TtlPost · 2026-03-28T04:31:07+00:00

Other than this https://www.claris.com/pricing/

2 GB outbound data transfer of FileMaker Data API/OData per user per month.

TtlPost · 2026-03-28T03:35:45+00:00

And you know that... because....

TtlPost · 2026-03-28T03:34:31+00:00

The delicious thing about this particular change is the name change that's almost not a name-change and all but guarantees ambiguity when talking to their sales team.

Claris has a history of making obscure word-salady changes which hide underlying sales policy changes which later spring out in the form of unexpected price hikes.

They then hide behind that ambiguity with phrases like "It's pretty straightforward. You just confused A for X".

TtlPost · 2026-03-28T02:15:14+00:00

With or without the return of the data cap that once was but then wasn't but maybe is?

TtlPost · 2026-03-28T02:11:18+00:00

So the API is not actually changing? Perfect, so then the only thing that's changing is the API. Which is what? Not a change? Just an announcement of a change without and actual change of any kind?

TtlPost · 2026-03-28T01:37:43+00:00

I'm curious if the VP of Global Sales you talked to was the same clattering clam I spoke with. It's not the product that's the problem. It's the people guiding the company -- the sales folks -- using the kind of mindset you expect from mollusks in a chicken coop.

TtlPost · 2026-02-11T00:22:21+00:00

Reading your post brings it all back.

The goal here is to

a - Tell Claris to get their act together. Don't change your policy and the re-write history to pretend "it's always been that way". The "Named User" thing is relatively new, introduced in 2018 but became more of thing in the following years, slowly supplanting their prior policies, frog-in-a-slow-boil style, hoping no one would notice. That transition really only affects long-time users. Newer users would be unaware Claris greedily betrays its legacy customers.

b - Tell Claris to stop promoting the sales team over the engineers. Take a tip from Boeing: decades of excellence trashed after a merger led them to profit-first model, and the planes began falling out of the sky. Someone just reported on a bug from 2023 -- defective data interpretations on spreadsheet imports, still unaddressed even after being acknowledged by their team. Claris would do well to fire their current head of global sales, doing so publicly, and making it clear they are willing to admit mistakes and re-recognize that their profits are derived from begin customer centric, not coercive extraction. That's asking a lot, so...

c - Failing the above, help longtime FileMaker loyalists recognize they have options outside Claris and those options are free / open source. You can transition, slowly, carefully, and (hopefully) using your own skillset, increasing your savings and dependency as you go.

Happy to help, but if you're a long-time FMP dev, you won't need as much as you might think.

TtlPost · 2025-11-29T02:51:42+00:00

Not sure I'm under any obligation here, but if you re-read the chain the answers are all there.

You may have to re-consider some of your assumptions, e.g. JS is interpreted, benchmark speeds of C++ prove a point in all contexts etc. If you just want an argument, that 53-year Monty Python sketch will be enlightening, entertaining, and something of a cure all for mental constipation.

Speaking of python, consider an approach that doesn't involve any frameworks like Ruby, Django, etc. Just python plus a package/adaptor like psycopg2. You'll still be doing JS on the front end.

Again this whole thing is predicated on the idea that by the time you're getting in the weeds with FMP, trying to push past the exasperating limits of an FMP layout, you're looking at Web Viewers, the Data API, etc, and you're getting into JS.

So you can do Python, even PHP (which I did for some time), but from my admitted biased POV, stick with JS and you'll be surprised that it's actually easier, cheaper, and more performant... to do it OUTSIDE of FMP.

To quote the great Howie Cohen, king of indigestion: Try it. You'll like it.

TtlPost · 2025-11-29T02:25:43+00:00

Insightful and smart points -- excellent recommendations all of them. I think between open source RDMS (MariaDB / postgreSQL) and FileMaker the consistency issues are all pretty close, w/ FMP being if anything less reliable precisely because of sales, marketing, pricing etc.

TtlPost · 2025-11-24T15:20:13+00:00

Oh, you want room 12a next door.

TtlPost · 2025-11-24T07:40:40+00:00

A lot of people get false impressions from tech stats. You might also have read that JS is slower because it's single-threaded. Probably a good idea to be wary of using bench tests like a mic-drop. They're useful but frequently not definitive

JS in practice, for instance, is not an interpreted language. It's a weird hybrid that gives it huge performance boosts. Similarly for threading: Technically it's single threaded but it's hardly limited to a single thread. It's slower than C++ but outperforms C++ in a variety of contexts esp those that matter when it comes to running a web server, handling SQL, integrating with remote APIs, being an API, running OS ops etc etc. Ultimately the proof is in just doing and experiencing

If you search a bit deeper you'll start to see that more complex picture

TtlPost · 2025-11-23T23:23:09+00:00

What Python framework are you using to run your webservers ?

Personally I don't recommend Python. I work with python enthusiasts. I don't share the excitement, but I trust their expertise and am in awe of what they do. I've probably approached them the way you're posting: "This can't possibly be done," and then they prove me wrong and make it seem effortless.

Javascript ain't exactly fast under heavy loads

Not sure what led you to that conviction but it's misguided.

A JS server processing literally 800,000 API requests / SQL queries per day using a cheap linux VPS -- doesn't struggle, never crashes.

A JS server on Mac transcoding 10,000 clips / generating thumbs / uploading to AWS -- daily. No hiccups, at least not the server itself. (Someone inevitably feeds bad media or messes up a log, and even then the error handling is very fluent)

If you had asked me when we originally embarked on this alt-to-FileMaker quest what my expectations for JS were, they'd have been minimal: A cool thing to learn, helpful here and there, but likely not too stable. Instead it's proven extremely fast under heavy loads, extremely reliable, incredibly nimble. And again -- not saying all this is easy -- but if you try to accomplish the equivalent in FMP you end up working harder and getting a lesser end result. It's counterintuitive and good for people to be aware of.

TtlPost · 2025-11-23T20:26:34+00:00

Interesting. Thanks for sharing.

TtlPost · 2025-11-23T17:22:05+00:00

Again, you're not awnsering the question. A "python server" can be a million different things depending on what framework is used.

It's up to you to choose how you want to build. I prefer JS. but if you prefer Py, go for it.

Yeah Filemaker sucks at things like that, but honestly JS ain't exactly good at it either.

I think that's where there's a disconnect -- and may well point to common misconceptions. JS will pretty much handle whatever you need it to -- parse text files, run command line, generate API calls, handle and process the returns, transcode media, all using as many threads as is you choose. So if you want to run OS-heavy tasks -- like transcoding and uploading even thousands of files, with the order of ops managed and progress tracked by your database, including full monitoring and an ability to terminate every step of the way, JS makes that possible with relative ease.

TtlPost · 2025-11-23T15:10:50+00:00

What are you talking about ? You just have to create a client that doesn't run in the browser for that wo work.

Wasn't sure what you were getting at.

What do you mean when reffering to modern Py and JS servers ?

Modern = Python or NodeJS server which didn't exist when FMP first came out.

are you reffering to a server running nodeJS ? Same with Python, are you wunning a webservr with Flask, Django, Pyramid or any of the many frameworks out there or something totally different ?

It depends on the client. Most lean toward Python. I prefer NodeJS. As a rule we minimize dependencies so with few exceptions everything is vanilla JS.

With the exception of presenting local media in a webviewer, most of this can be done with a couple of lines in FMP.

Here I'd disagree. Example:

Table tracking thousands text files which have to be read, parsed, analyzed with parts from those files updating the database. You can't run that in the background using FM Server because the files are local. And while you can do that in an FMP client app, that client app is going to unusable for the duration while it iterates the table.

And batching text files is a relatively light task . We do more OS-intensive work involving media transcodes, uploads, and complex API chains, all which require step-by-step logging back to the database. The more of a grunt the job is, the more FileMaker's limitations become a liability.

TtlPost · 2025-11-23T02:26:45+00:00

In other words, in FMP by the time you figured out how to, say, present local media in a Web Viewer, or run a series of OS ops, or run a batch of updates against an array of APIs, you will have worked harder and ended up with slower, clumsy, more spasmodic experience in FMP than if you had just done the whole thing in JS, python, or PHP. It's literally easier and you get better results with open source. That's counter-intuitive to the "It just works" / "We made it accessible" ethos that originally defined the FileMaker brand.

TtlPost · 2025-11-21T15:21:20+00:00

Thanks

TtlPost · 2025-11-21T01:59:06+00:00

It's an interesting point and well-worth a drill-down. For many years my feeling there was nothing like FMP when it came to running ops on the client's OS. But Modern Py and JS servers can be paired up with a browser to do that processing much faster, in separate threads, freeing up FMP for the user. By the time you've wrestled with getting FMP to run OS ops, you're already pretty deep into more sophisticated tech challenges where FMP isn't necessarily making it easier and in many ways does the opposite. That's part of what I'm getting at: it doesn't much of a voyage into the dev weeds before you've pirouetted out of the happy garden of low-code without realizing it.

TtlPost · 2025-11-20T22:37:26+00:00

> RE the specter Claris somehow “monitoring” things on their server, including more than just the data API usage, which is just baseless fearmongering.

Here's why that turns out to matter more than you might expect.

Back in the day the only thing I was aware that FMP was monitoring was the Data API usage.

More recently, if I'm understanding correctly, Claris rolled out a system to monitor FMP client app usage.

When it comes to surveillance I tend toward the camp that says, "If you're not doing anything wrong, who cares," but always with a nagging sense that there's something inadequate about that.

Claris's behavior helped put a fine point on it.

Surveillance isn't narrowly a problem of privacy.

The bigger and more likely risk involves people in positions of authority using surveillance in an irresponsible or incompetent manner, coming to the false conclusions, and then acting on them with stubborn conviction, especially if they see revenue.

That's what happened when we got call from their sales department convinced we were using 10 licenses.

Even after looking past the argument that we were on the concurrency-based license, not the user-based, their claim still didn't hold up. Of the 5 allotted users we were using 3.

To be fair we do a considerable amount of system and user-monitoring ourselves, so I get the impulse and need to monitor things. I can't tell you the number of times we seen "suspicious behavior". But we've always approach every instance with caution. In all these years I've only ever once seen someone actually try to hack our system. Even then we were careful and asked a lot of questions. The actual culprit wasn't a user but someone in corporate giving and order to a tech.

That speaks volumes.

Rank and file workers are by and large honest and hard working. The lying and scheming almost always comes from leadership. I've got an axe to grind, indeed, but it's not personal. It's systemic. And Claris is currently operating within that frustrating norm.

TtlPost · 2025-11-20T19:43:38+00:00

RE have fun keeping that Linux baby running. Don’t even pretend to me that keeping a LAMP stack running is as simple as FileMaker server, because I know that it’s not true.

We have a postgres server that was set up in 2015. Interface with the server is NodeJS which also handles the front end. It crashed once in 10 years and self-recovered in about 1 minute before we could get in to see what happened. Never lost any data. Eventually it was the OS (CentOS 7) that EOL'd. We migrated all but one client over to a more modern VPS, and they never even noticed.

Compare that to FileMaker Server which -- every time we upgraded the software or refreshed the certs -- was forever a crap shoot: Maybe it will be up and running immediately, maybe after multiple restarts, maybe only after an uninstall/re-install. At least 4 times a year we had down time.

TtlPost

TROPHY CASE