Home / Blog / FileMaker / FileMaker Server 16: FileMaker Data API
12May 2017

FileMaker Server 16: FileMaker Data API

About the Author

Wim Decorte Wim Decorte

Wim is a Senior Technical Architect at Soliant. He is a FileMaker 7, 8, 9, 10, 11, 12, 13, 14 and 15 Certified FileMaker Developer and the author of numerous Tech Briefs and articles on FileMaker Server. Wim is one of the very few multiple FileMaker Excellence Award winners and was most recently awarded the FileMaker Community Leader of the Year award at the 2015 FileMaker Developer Conference. He is also a frequent speaker at the FileMaker Developer Conference and at FileMaker Developer groups throughout the world. In addition to being a renowned expert on FileMaker Server, Wim also specializes in integrating FileMaker with other applications and systems. His pet project is the open source fmDotNet connector class that he created (

Comments (5)

Gianluca - May 17, 2017

Hi, thanks a lot for this very useful article.
It works a treat!

The question that I have is how can I build a Filemaker to Filemaker data exchange with this?
Let’s say I have a Filemaker Go file that I want to sync with the database shared in FMServer, I could use the GET to retrieve all the records I need and load them into the Filemaker Go file. I was thinking of a text field in the FMGo file that I set with the “Insert from URL” instruction so I can get the data and then split them into a local table.

Do you think is possible?

Thanks a lot!

    Wim Decorte
    Wim Decorte - May 17, 2017

    Hi Gianluca,

    Thanks for the feedback. Yes; as a concept that would totally work. Note that ‘insert from URL’ now supports setting a variable directly so you wouldn’t have to store it in a field.

    One thing to keep in mind: when the Data API is released officially it may come with a licensing cost so take that uncertainty into account when defining your strategy.

    Best regards,

Hans Erik Hazelhorst - June 21, 2017

Hi Wim,

Thank you for this excellent introduction and for taking the time to make this documentation. The data API looks very promising and following this intro is also valuable as a way to get accustomed with webservices in general, PostMan, and oAuth.

Two questions:
1. Is there a special reason why you use two fmp12 files for this example? I am a proponent of data-interface separation myself, but other that that, are there security reasons for this choice?

2. I heard recently that the RestFM solution from Goya Ltd (which uses the PHP API) is preferred by some developers because it has better security and other features. Notably, the ability to run scripts as part of a API call handling. Do you have any ideas on that issues that may help me choose one solution over the other?

Beste Regards,
Hans Erik Hazelhorst

    Wim Decorte
    Wim Decorte - June 21, 2017

    Hi Hans,

    Thanks for the feedback.
    No special reason for the data separation in this demo, except that I wanted to verify that it works ok for those types of deployments. No security reasons.
    We have used RESTfm in various projects over the years and will continue to evaluate it for the task at hand. One of the major drawbacks of the new Data API clearly is that we can’t run scripts. We can still do it through the XML API if need be while using the new API. For us it is mostly the uncertainty around the Data API licensing model that could prevent us from using it. It’s security is good though so that would not turn us away. RESTfm does offer some more options all around.

Leave a Reply