Yep, good idea - I could return the server timestamp in all API responses. The only problem I can see here is that because a lot can happen at the same time, if the client relies on the timestamp being the exact point that data is read, it’s possible for a parallel write to have a timestamp before the read but is not yet visible to the read due to the way RDBMS transaction isolation works… only the matter of milliseconds, but still possible.
So, whatever I do, it’s probably safer for clients to assume that they may receive duplicate items if they’re being retrieved based on the time. A “safer” way would be to provide a serial event number where the client says “last event I received is 12345, send me everything from event 12346” but this means a greater amount of smarts on the client, a more complex API, and more complexity on the server to assign sequential event IDs on the server.
I’ll go ahead with the timestamp in API responses and the ability to send timestamp instead of “loopback-seconds” and see how it goes.