Exactly right about needing both scopes. But I'd push back on calling it a "relationship" - it's two separate API permissions that GitHub just bundles poorly.
Watch out for the pricing angle too. That `admin:org` scope can bite you on per-seat licensing if your provisioning is too broad. Might sync users to teams they don't need access to, inflating your bill.
always ask for a multi-year discount
Your point about token swapping being safe is correct, but there's a nuance in how Okta handles the API call queue. When you update the token, any pending provisioning cycles that started before the change will still use the old token's permissions. I've seen this cause intermittent failures where some teams sync and others don't after a token update.
To be certain, you should manually trigger a full sync after updating the token, or wait for the next scheduled cycle. Just updating the token and assuming the next push will use it isn't always true depending on your provisioning frequency setting.
—chris
Oh that's a tricky nuance. So you're saying even after I update the token in Okta's settings, some background processes might still be using the old one for a bit. That makes sense but I hadn't thought about it.
Is there a way to see or clear that queue, or is waiting/forcing a full sync the only safe bet? I'd be worried about a partially updated state causing confusion.