#g_g_s_p
mellow sable
Hi! Let me help you with this.
Good question, I am not sure. Let me check.
Why do you need to change it?
shell trout
It may have leaked and I'd rather be safe than sorry if that makes sense
dim bisonBOT
g_g_s_p
mellow sable
It might not be possible, unfortunately.
shell trout
Ah, I see. Is it on the roadmap?
mellow sable
I will let the responsible team know, but I can't guarantee if or when it will fixed.
Is it a live key?
shell trout
It was used in development and is about to be used in production—I wasn't aware it'd be the same key across the board (i.e. I thought it would be tied to the stripe-cli instance so to speak) so when I used stripe listen --print-secret on our production server and got the same key I was wondering about whether we could roll it to cover all of our bases. Either way, I don't think it's blocking for us, we will go ahead and use the same key in production if there's no other option
mellow sable
I would recommend against using Stripe CLI to listen to Live events.
I am not sure if it's the Live webhook key you're seeing on your production server. For that you would need to run stripe listen --live
shell trout
Oh I see—we were planning to just add stripe listen --forward-to localhost:3000/webhooks -c localhost:3000/webhooks to our Procfile. Is this bad practice? If so, do you mind pointing me towards the right way of doing this?
mellow sable
The right way to do webhooks in production is to register a webhook endpoint in your Dashboard, pointing at a publicly accessible endpoint in your production server.
shell trout
I.e. using https://dashboard.stripe.com/webhooks/create ?
mellow sable
Exactly
shell trout
Ahhhh that makes so much more sense... Awesome, I'll do it that way. Thank you for taking the time, Vanya!
mellow sable
Happy to help!