For each table you want to sync, there needs to be a layout that RESTfm can use to publish the data from. In our sample file we've gone with a consistent naming convention of "TableName.RESTfm" for each of the layouts so we know what is being referred to. It will be much simpler if each layout is named after the BaseTable in some way, so you can use your own naming convention, but keep it consistent.
Onto this layout you need to put all of the fields that are being synced. So you should all all stored fields, but no calculations, globals or summary fields.
The sync specific fields you added in the previous steps MUST be included on the layout for the sync to function.
APIs and Versioning
You can use naming conventions to have versioning with your syncing. So some clients are syncing to v1 of your file, and some are syncing to v2 etc, when there are new fields added.
To do this, add an extra extension to the layout name. So "layout.RESTfm" becomes "layout.RESTfm.v1" for example. Then when you want to add fields or more tables to the layouts, instead of modifying the layouts that are in use ( and possibly breaking sync by doing that ), just duplicate them, and call them .v2. Make any changes, such as adding or removing fields and you can distribute a new version of your solution that syncs to the new set of layouts without breaking the old sync clients.
Within the sync code ( in the next sections), there is a parameter in the Main setup for "LayoutNameExtension" where you can specify which version of your server files you are sending to.