For those of you who use Make.com, you have recently received a message from Make about updating your Stripe modules to use the new Stripe Restricted API Key (RAK).
I started to wonder whether any similar updates might be required in Softr’s Stripe integration to utilize the RAK.
Would be interesting to hear from the Softr team, as well as from the user community.
This is a relief. Apparently Make gave their users 2 days notice to change their keys to RAK. Also noticed their Stripe docs need more clarification for integrations .
I’ve submitted a ticket to Make.com on this. Yes, their documentation on changing the key does not align well with Stripe’s.
The reason I’ve submitted a question on this forum is because Make.com made it sound very urgent and “a must do”. So, the immediate thought was - is Stripe pulling away from their old keys? And if so, do we need to take care of it in Softr, too?
I have yet to receive response from Make.com on this. For now, both the old Stripe key is still working in Make and the new Stripe RAK key I’ve set up is working, too.
I got a reply to my ticket with Make.com and the existing Stripe keys would be deprecated in favor of RAK. Not sure when…
message
Recently, Stripe announced that it is enforcing a new policy using API key auth. Starting in June 2024, we(Make) are introducing a new authentication method using Restricted API Keys (RAK) . The current API key authentication will be deprecated .
To avoid potential additional charges from Stripe, please update your existing connections and create new ones using the RAK . This will ensure your scenarios continue to run smoothly without any interruptions.
Checking back on this, as Softr is asking for the secret key but Stripe is telling me not to use it. Can you please advise? Should I go through the Restricted Access Key processes to connect Softr to Stripe? (Choosing the top option brings you to the Restricted Access Key process.)
Yes, RAK is the way to go. Fundamentally, it’s the same thing as the regular key, with the only difference being more secure (hence - restricted) by way of specifying the domain (application) from which the API calls can initiate.