Best way to determine when to delete personal data

Hi @PluginGenie,

Our apologies for the delayed response while trying to confirm the best way possible. The team recommends webhooks based on reliability and industry standards.

Please let us know if you have any other questions!

Best,
Rachel

Oliver,

We are using the uninstall webhook to the app events to trigger setting a deletion date. (not subscription ended/cancelled because we have a free tier where the app continues to function). Deauthorizing/Deactivating seems legalese since there is no object/event tied to that which we can access.

I absolutely concur that this webhook needs to have retries if we do not respond with a 200/202 response to say we got it. Right now it will not retry even if we return a 500 error. It should retry with an exponential backoff for a period.

Any long term failures should then appear in a view in the developer section to allow us to manually retry them when we’ve resolved the issue.

Thanks for the info! I would feel much more confident using webhooks if it had the features you mentioned. It seems risky if only one is sent by monday without any retries if it’s not a success response.

There is are several issues with looking up status using a stored token.

• You have to actually store a token to start with. Many apps have no technical requirement to do so, and from a security perspective should be using a seamless authentication method not OAuth token.
• If the app gets uninstalled the token is invalid and you get a 401
• If the account of the user whose token you got gets disabled/deleted you also get a 401, however you do not know the app has been uninstalled.
• You can only get an OAuth token when they install a feature or recipe - no longer can on app installation.

Now, you could using seamless authentication methods have a check “on usage” where your app checks when it receives an integration event, or a UI feature can poll your backend to see if it needs to check and report back the result.

But this all seems hacky to me, just making the webhooks require a response is good. Install should also require a response - and if we return a non-200 response the app install fails for the user. That way they don’t get an app installed that then fails to function because we’re rejecting it because we don’t see it as installed.

Those are some excellent points. You’ve convinced me that a webhook makes the most sense, even with its current limitations.

one thing con consider doing, is to store the event in a queue as soon as you finish authenticating it, then process from the queue. Like AWS SQS type queue. Then any processing errors you have it can get put in a failure queue or dead-letter queue, and you’re able to resolved errors from there.

That way there is some temporary persistence of data so you can reprocess it later.