Hey Proof+Geist,
Is there a way to record the label of the api key that was used in a webhook call?
I ask this only because if I create a specific API key for each user who I give access but they all share the same FM account credentials, I have no way to tell who sent the web hook request. Unless its there but I’m not seeing it (I might be missing it).
All the best,
Nat
Hey Nat,
Are you trying to record this label in your application with the payload that OttoFMS sends along or somewhere else? We could send that label along in the payload, at the moment it does not get sent. Thank you!
-Kyle
Hey Kyle,
In theory yes adding to the JSON payload would work. I’m afraid modifying the payload by automatically adding the attribute could disrupt existing workflows where they expect an exact JSON object equal to the payload.
Maybe a toggle in the webhook UI to add it to the payload JSON?
Except web hook accept a valid JSON array as well where yo couldn’t add a new attribute. The other option would be to add a field to the OttoReceiver table but then you’d have to release a whole new Add-On.
This may not be feasible in the end.
-Nat
Hello Nate
Using separate credentials for each user, would be one way to do this. But that might not feasible in all use cases.
I think there is something to this idea. But it may be that we have to expand our thinking a bit on how to pull this off.
Todd
I think the label could be added in the OttoFMS logs, but I don’t think injecting it into the payload would be a good idea.
As Todd suggested, separate credentials for each user is the best way to get that data into the FileMaker file. We’ve seen this method used in other systems and it’s why we built the returnExisting option when creating API keys so that you can programmatically generate API keys for each user without creating a bunch of unnecessary duplicates.
Thanks for validating my thinking here Todd. It’s much easier to create and manage API keys through OttoFMS (especially with the developer API endpoints) than to manage FileMaker user accounts, especially because each one will still need its own API key.
And thanks Eric. returnExisting is a huge help for this in general. Totally agree that adjusting the payload would be bad/dangerous.
Appreciate the consideration.
-Nat
We could do something similar to what we do with the query params and the headers in the webhook options, where you could choose to inject them into the payload on a case by case basis.
That would prevent it from screwing up everyones webhooks and it would match the existing webhook paradigm we have going.
-Kyle
I totally see how that would work Kyle. That still requires the outgoing call to include the parameter, which puts onus on the client system that makes the call.
I was hoping it could be set on the webhook definition itself in the OttoFMS Web Console. I understand that’s a new paradigm though.
In the end, if I really need the user to better identify themselves than I can just require that in the payload and validate it in the FM scripting that stems from the OttoReceiver.
-Nat
Hey Nat,
Having settings on the individual webhook would be a new paradigm, although it is not necessarily a bad one. We’ll think about this and see what we can come up with. For now the best solution would be something like Eric and Todd’s suggestion I believe.
-Kyle