[sneak]

If you are using signing secrets, consider having the client keep a secret and simply encrypt and sign the payload before handing it off to you.

When it comes back in, they can decrypt and authenticate it. You could hide all this in your api client.

Then you don’t end up with a big centralized database full of the PII of millions of your customers’ customers.

[skaiser]

So are you suggesting that we update docs to encourage users to do that? We use signing secrets to sign the payload so users know the request from us is authentic, but other than that I can't think of how we'd control what users send us aside from just rejecting anything that "looks" like an object ;)

I do like the idea of including a little chunk in our SDK (Coming soon!) to allow them to easily encrypt/decrypt their payload, but that'd be entirely on them to follow that practice.

[sneak]

Defaults matter. Make the api client encrypt everything it sends to you, so you never handle unencrypted customer data.

[skaiser]

Oh for sure, I just haven't thought of a way to enforce that the payload be encrypted because there are so many different methods to do that and most of them still result in a string...

Do you have any advice or suggestions for how to enforce that?

I'll definitely add some docs to encourage it though; thanks for the suggestion!

[sneak]

When I say “make”, I mean in your own api client library. It should happen automatically so the user doesn’t have to think about it.

You can provide some functions for the webhooks so targeted to authenticate and decrypt the stuff posted to them.

[skaiser]

Ah gotcha. Yea we'll 100% include that as part of our SDK. Thanks for clarifying!