New strava policy and dev, test, prod accounts

Dear ​@Mark_AJ ,

Thank you for your reply!!

I’m not yet accepting any registrations yet, so no I’m only testing with a few people still below the limit of ten people.

On my side I’ve duplicated the infra for test and production. So I can do most of the testing on my server. However the callback domain is limited to one url. So that should be connecting to the production environment. But how can I have people connect to test with only one callback domain. Also I was thinking that the webhook registration would only allow for one per client id. So testing the interaction between the Strava API and my software is not possible without impacting the user community.

do I make mistakes in my assumptions and reasoning?

kind regards, pieterbas

Hi ​@Pieterbas, you could use a single client ID and simply have your production environment relay the webhooks to your dev/test environment(s). 

On a related note, there’s currently no way to authenticate the Strava webhooks, so I’d suggest having your prod use an IP whitelist for incoming webhooks (see https://communityhub.strava.com/developers-api-7/whitelist-ip-address-webhook-1840?postid=20447#post20447), and your dev/test whitelisting your prod IP.

Hi ​@Pieterbas since you're still under 10 users you're overthinking this because that 10 limit is meant to be a sandbox for testing, you can go wild. You can test directly on your prod environment for now which is what this sandbox tier is meant for, you can gate registrations with an invite code or similar so unknown users can't sign up if that’s what you’re worried about.

Another way to do this is to introduce Feature Flags. Deploy the new webhook handler behind a flag, test it with real webhook events against a subset of whitelisted ids. You can route data to another table in the db gated behind that feature flag so that means in prod you’ll have existing features and new features behind feature flags working together which also helps you do A/B testing. For example user A who is non-whitelisted may see your live production version, then User B who is whitelisted and happens to be on the same production callback will see a new feature but their data routes to both the feature flagged table and the original one in production so you can always flip back and forth.

Hi ​@Mark_AJ , ​@Cyril ,

Thank you for your feedback, I’m going to simplify things and go back to one client id and find a trick to be able to test on my side.