OData Table Trigger not firing on one table, works fine on another in the same file

OttoFMS
1

Hi all,

First post.

I’ve been troubleshooting a table trigger issue and have narrowed it down pretty thoroughly. Hoping someone has seen this or has ideas.

Setup:

  • FMS 22.0.6 on Ubuntu 24.04
  • OttoFMS 4.16.1
  • Three triggers registered on the same file, same webhook URL, same credentials (full access admin)
  • Triggers created via Postman (Webhook.Add) and verified with Webhook.GetAll — all three show ACTIVE status

Results:

  • Table A (invoices table) — triggers fire :white_check_mark:
  • Table C (brand new test table with 2 simple text fields) — triggers fire :white_check_mark:
  • Table B (estimates table) — never fires :x:

All three appear correctly in Webhook.GetAll with ACTIVE status and zero pendingOperations. Table B stays at zero pendingOperations even after editing records — FMS isn’t detecting the changes at all. It’s not a delivery problem.

What I’ve tried on Table B:

  • Removed all select/filter parameters
  • Renamed the TO and recreated the trigger
  • Closed and reopened the file on FMS
  • Deleted and recreated the trigger multiple times (via both OttoFMS UI and Postman directly)
  • Verified the TO appears correctly in OData metadata
  • Edited directly in FileMaker Pro on a layout based on that TO, committed the record
  • Full access admin credentials
  • Added a brand new stored text field, put it on the layout, edited it — still nothing
  • Confirmed the base table is in the same file (not external)
  • Removed broken auto-enter calcs with references
  • Changed repeating fields (maxRepetition 15) back to maxRepetition 1

None of it made any difference.

What’s different about Table B:

  • Larger table with more fields than the others
  • Has several unstored calculation fields that reference related tables (JSON builders)
  • Has stored calc fields as well
  • Had some auto-enter calcs with broken field references (since cleaned up)
  • Originally had repeating fields (since changed to single rep)

Secondary finding — OttoFMS UI bug:
When creating triggers through the OttoFMS Triggers UI, some triggers appeared in the OttoFMS console but did not actually register with FMS. Webhook.GetAll showed fewer triggers than the UI displayed. Creating triggers directly via Postman (Webhook.Add) consistently registered them correctly. Just a heads up in case others run into phantom triggers that don’t fire — verify with GetAll.

Environment:

  • FileMaker Server 22.0.6
  • Ubuntu 24.04
  • OttoFMS 4.16.1

Has anyone seen FMS silently ignore changes on a specific table while triggers work fine on other tables in the same file? Is there something about a table’s internal structure (field count, calc complexity, table age) that could cause the OData webhook engine to silently skip it?

Thanks for any insight!

2

I am going to assume here that your select is empty?? and also have to guess what your $filter contains…
Have you tried the .Invoke(n) method to see is you can force it to fire?
Have you tried just $select=ROWID – not asking for any ‘data’ from the table

repeating fields not likely to be the cause (OData supports them) field naming is one possibility, unstored calcs often an issue, try a webhook with none excluded

lets us know what your use case is too, as maybe webhooks is not the right thing to do

3

Thanks for the suggestions. Tried them all:

  • Invoke: getting errors regardless of syntax on FMS 22.0.6. Tried POST with the webhookID in the URL, with/without body, always fails.
  • select=ROWID only: still doesn’t fire. Zero pendingOperations. So it’s not a field issue at all.
  • Empty select (all fields): same result.
  • Filter with ROWMODID gt 0: same result.

At this point I’ve tried every combination of select/filter/no select/no filter and this specific table just won’t trigger. Two other tables in the same file (including a brand new test table I created just to verify) fire perfectly.

As for use case, I’m building a one-way real-time sync from a legacy file into a new system. When an estimate record changes, I want the trigger to hit my endpoint so I can pull the updated data and migrate it over. The invoice table trigger works great for this. Just can’t get it working on estimates.

Starting to wonder if there’s some internal table-level issue that’s invisible from the schema side.

4

make a new file, copy the table, add a new webhook, add a record
does it fire?

if no then its a field issue
if yes import the records to that table
modify a record, does it fire? if no then it looks like corruption in you source file/table
add a record, does it fire?

if no
copy the file, add a webhook to that table, does it fire?
do a recover on the copy, any difference?

if still no, do a clone, recover teh clone
same as above - add one, import from recovered, does it fire?