Events vs Stati

[cdaguerre]

@aponsin To my understanding, callbacks are triggered by status changes. Do callback endpoints receive more than the current state of an object? Stati are not events as such, right? Consider these state transitions for instance:

Previous status	Current status	Event
in_creation	in_progress	created
paused	in_progress	unpaused
review	in_progress	modifications_requested

I think it would make sense to also get information about the previous state of the object, at least it's previous status. Maybe this already exists, but I haven't had the chance to check a webhook payload yet.

[aponsin]

Correct, callbacks are triggered on status change of documents or projects. When you receive a callback, you will receive as a payload the GET equivalent on that object.

The list of all possible callbacks are defined here: https://eu.textmaster.com/documentation#principles-callbacks

However we do not offer a "previous status" field.

[Pitoune]

Great ! I have a security issue here. How could we verify that the POST is from you ?

• Do you have a specific header we could trust ?
• An IP address we can filter ?

[aponsin]

Hi, we don't have any "real" security measure to authenticate ourselves to you when doing a callback post. The approach we usually take, is that we let the client (you) generate a sort of security token that they set in the callback url so you can verify it was passed back. Example:

Callback url: https://tm-callbacks.mysystem.com/document_in_review?token=19xe8j1982j11dnd You set that on TM side, so that way if you have "anyone" trying to make a POST on https://tm-callbacks.mysystem.com/document_in_review you can verify that the token 19xe8j1982j11dnd wasn't passed along and that therefore it's not textmaster.

If you want added security you can even obfuscate the URL: https://tm-callbacks.mysystem.com/someCrazyURLmad2983jd2983dj98?token=19xe8j1982j11dnd