+23FME Server has a good range of Rest api calls but they aren't all documented. For instance, named connections are avaliable by fmerest/v3/namedconnections/webservices, version control push by
/fmerest/v3/versioncontrol/remote/push. It would be great if more of these calls could be documented
+16Understanding that some API calls are undocumented for the reason that they are liable to change in subsequent releases, perhaps those "unstable" calls could be hidden by default and only exposed with explicit selection of a checkbox similar to the "Hide Advanced Calls" checkbox on the current API documentation. Maybe something like "Show Beta Functionality", with appropriate warnings beside each such call in the documentation.
Noting Ideas created for specific endpoint exposure here as well:
Automations Components: https://knowledge.safe.com/idea/111914/publish-fme-server-rest-api-endpoints-for-retrieva.html?
Named Connections: https://knowledge.safe.com/content/idea/43115/named-connections-editing-via-api.html
Version Control: https://knowledge.safe.com/content/idea/75121/expose-versioning-through-the-fme-server-rest-api.html
+14Thank you to everyone who has voted and commented on this! We have marked this idea as 'Under Consideration' because we have started work on the next iteration–Version 4–of the FME Server REST API.
Currently, we plan to have V4 as "Technical Preview" for 2021 and we expect that it will be a full release cycle until it takes place of the V3 REST API (i.e. FME Server 2022). Expect more details to come (e.g. migration guide) as development progresses.
We have made note of the requests in this idea description and those in the comments. Any major updates or decisions related to those requests will be posted here.
Hi @rylanatsafe, any news on the availability of v4 and the API for named connections in particular? Ideally, we would like to leverage the API to create and maintain database connections in an automated manner. Use case: update database connections programmatically to point at different staging or test servers. This includes modifying the password.
+14@david_r the V4 API endpoints for web and database connection management will be in progress soon.
Updating parameters, such as the db connection password, should be in scope for this work.
+18
+18+18+18+14I am happy to say that the FME Flow V4 API is finally released with 2025.1—it was a long time in the making! A huge thank you to everyone who tested it, submitted improvement ideas, and shared your unique use cases.
Some areas of Flow still do not have exposed API endpoints—many of which were also missing in the V3 API. We're actively working on foundational infrastructure changes and want to avoid breaking backwards compatibility in the V4 API. We appreciate your patience as we continue this work (which is underway today).
The V3 API is scheduled to be removed in FME 2026.1. If you haven’t started yet, now’s a great time to begin migrating to V4. We’ve provided a migration guide (available in your FME Flow 2025.1 deployment at <hostname>/fmeapiv4/docs/index.html) to help. If the guide doesn’t answer all your questions, our support team is here to help!
+12
Also - let’s say I am in the middle of developing an application that should be compatible with any version 2022+ - then that has to be v3 up until 2025, and it can’t be v3 only to be futureproof for 2026… Or can it be v4 all the way… ?
+14
If you’d like to send me an email (rylan.maschak at safe.com) detailing the endpoint groups (e.g. /jobs) or specific endpoints, I could look further into the specifics, but generally speaking, not until 2025.1 is it recommended to begin building workflows solely with the V4 API.
+55regarding this Migration plan document, available in your FME Flow 2025.1 deployment at <hostname>/fmeapiv4/docs/index.html) for help
I queried AI assist and it provided some really good tips, but it hasn’t picked up on the fmeapiv4/docs
FYI
+12
+14
