On the tasks:

• I don't think we need a background job to connect the app.
• We need an input field for the API key (called PAT = Personal Access Token here) which is new. The other apps don't have that.
• The controller needs to forward params like the PAT to the specific ConnectedApp class.
• It can then store that in the database and be connected instantly, assuming that the PAT will work.
• We could try the PAT first and tell the user if it's wrong. That's a nice-to-have though. I wouldn't do that in the background though because instant feedback to the user is more useful here.

• It can then store that in the database and be connected instantly, assuming that the PAT will work.

• We could try the PAT first and tell the user if it's wrong. That's a nice-to-have though. I wouldn't do that in the background though because instant feedback to the user is more useful here.

I am bit sceptical on not checking the PAT when turning on the connected app. It would make tracking down a wrong PAT harder, as we will probably realised the PAT is wrong when a customer tries to redeem a voucher for the first time, plus it would lead to a bad UX.

It should be pretty quick to check the PAT directly against the API and provide the ability to re enter the PAT if doesn't work. Agreed on not doing that in the background.

@maikel What do you think ?

Yes, I'm happy for that, too. Definitely better UX.

just commenting that I belatedly saw @RachL suggestion about possibly doing this on the voucher page and I quite liked. Perhaps one for delivery circle tonight

Updated the estimate with more details on this is going to work, based on Maikel's feedback