Public (legacy) app — incremental scope re-authorization fails with "app governance settings" error

Develop, Build & Integrate APIs & Integrations
1

We provide an iPaaS service. We created a public app on the legacy app platform and issue its client_id to our customers. Each customer authorizes the app by selecting their own account during the OAuth flow. Our design requests only the scopes required by each workflow (integration), so the scope= parameter in the install URL varies per workflow.

Recently we’ve seen the following behavior in two customer accounts, and we’d appreciate any insight into the possible cause.

Assumptions / context:

  • Our app’s scope configuration appears correct (only oauth is set as required; all other scopes are registered as “conditionally required”).
  • The user performing the authorization is a Super Admin.
  • The scopes shown in the error are all standard CRM scopes, of the same kind as other standard scopes that authorize successfully — they are not plan-gated advanced scopes.

Case 1 (clear, reproducible):

  1. A customer first authorizes a workflow that requests scopes A, B, C → succeeds.
  2. They then try to authorize a different workflow that requests scopes A, D, E, and get this error:
    Authorization failed because this app hasn't been approved to access the required scopes [crm.objects.companies.write, crm.objects.companies.read, crm.schemas.companies.read] in your account. Please reach out to your account super admin to add the app's permissions in your account's app governance settings.
  3. If they uninstall the app in their account and then re-authorize with A, D, E, it succeeds.
  4. But if they then try A, B, C again, it now fails with B and C reported as unapproved.

In other words, scopes added in a later authorization are rejected instead of being approved on the consent screen. Previously (and for most other customers), re-authorization succeeded even when additional scopes were requested.

Additional observation:

  • In the customer’s “Connected Apps” screen, the app appears under the “Connection home” tab but does not appear under the “Approved apps” tab. (In our own test environments as well, the app shows up under “Approved apps” for some accounts but not others.)

Case 2 (possibly related, different error):

  • For a different, newly onboarded customer, the error message was different: “An unexpected error occurred during the app authorization process.” This account had no prior issues on our side. Reducing the set of requested scopes and retrying resolved it.

We’re not sure whether Case 1 and Case 2 share the same root cause.

Questions:

  1. Is it a recent behavior change that re-authorization requesting additional scopes no longer completes on the consent screen and instead returns this app-governance error? If so, what is the correct way to approve the additional scopes?
  2. For an account where App Governance is in effect, what is the proper way for a customer (Super Admin) to approve additional scopes for a public app? We don’t see a way to manually add a non-marketplace public app under the “Approved apps” tab.
  3. What determines whether an app appears under the “Approved apps” tab for a given account? We see it appear for some accounts but not others.

We’ve reviewed the relevant documentation but couldn’t find recent information matching this behavior. Any guidance would be appreciated. Thank you.

3

Hi @developer and welcome, it’s a pleasure to have you on the HubSpot Community! :orange_heart:

Thanks for the detailed information. When researching for you, it seems that this is a known behavior change associated with App Governance.

Regarding the Case 1: Re-authorization rejecting additional scopes

Accounts enrolled in App Governance are routed differently now. Uninstalling and re-installing resets the state, so this could be a workaround for you. Our team is aware of this and is working on a solution as we speak.

How to approve additional scopes:

The Super Admin needs to go to:

Settings → Integrations → Connected Apps → “Manage approved apps”

and explicitly approve the additional scopes for the app.
Here is the article about it: Manage access to apps

There is currently no way to manually add a non-marketplace public app to the “Approved apps” tab outside of this governance approval flow. The app appears there only after the governance approval has been completed for that account.

This is why you see the app under “Approved apps” for some accounts but not others, it depends on whether the account is governance-enrolled and has completed the approval flow.

Regarding the Case 2: “An unexpected error occurred”

This is a generic error (UNEXPECTED_ERROR), it might be a validation or processing issue with the full scope set. The fact that reducing scopes and retrying resolved it is consistent with a scope-related validation failure. If it happens again, sharing the correlation ID and timestamp would help investigate further.

So, here are the recommended workarounds:

  1. For affected customers now: Have the Super Admin pre-approve all scopes the app might request (across all workflows) in Settings → Integrations → Connected Apps → Manage approved apps, before any authorization attempt.

  2. Alternatively: Include all conditionally required scopes in every install/re-auth URL (PUT semantics) rather than varying them per workflow. This prevents scopes from being stripped during re-auth.

I’d also recommend to monitor the public changelog ( Public App Reauthorization and Advanced Scope Settings ) for any updates.

I’d love to hear from our Top Experts: Hi @sylvain_tirreau, @SteveHTM and @zach_threadint do you also experience this behavior, please? Do you have any insights to share?

Thanks so much and have a brilliant day!

Bérangère

This post was created with the assistance of AI tools

4

Hi @Berangere ,

Thank you so much for such a thorough and helpful reply. I really appreciate you taking the time to look into this and explain the workarounds so clearly. It has given us a much better understanding of what’s happening, and it’s reassuring to know that your team is already aware of the issue.

For the customers currently affected, we’ll proceed by requesting a broader set of scopes during the initial authorization, as you suggested, so that later workflows remain within the already-approved scope set.

If possible, I’d like to confirm two points to help us plan our longer-term approach:

  1. Is this behavior expected to be fixed?
    You mentioned that your team is working on a solution. Is the intention to restore the ability to approve additional scopes during re-authorization? If you have any rough indication of timing, that would also be very helpful for us when communicating with our customers.
  2. Or is this expected to remain the intended behavior going forward as App Governance rolls out more widely?
    In other words, should we treat “always send the full set of scopes on every authorization (PUT semantics)” as the correct long-term integration design, rather than as a temporary workaround?

Understanding which direction to expect would help us decide whether to adjust our integration design or treat this as a temporary issue and wait for a fix.

Thanks again for your support — it’s genuinely appreciated.

Best regards,

5

Hi @developer and thanks for following up! To reply to your questions:

1- Yes, this is a recognized regression, not the intended permanent behavior.
The team is actively working on a fix to restore additive re-authorization as the default, however, we don’t have a timeline to share at this time.

2- This is a temporary workaround. That said, even under the fixed additive behavior, there is a governance approval dimension that remains: on App Governance-enrolled portals, conditionally required scopes that were not part of the initial approval must still be explicitly approved by the Super Admin under Settings → Integrations → Connected Apps → Approved apps → Manage access.

We’ll share updates on the public changelog I shared in my previous reply.

Thanks and enjoy the weekend!

Bérangère

6

Hi @Berangere ,

Thank you very much for the clarification and for taking the time to follow up — this was extremely helpful.

I understand things may still be evolving on your side, so no worries if there isn’t a definitive answer yet. If any further details become clear, we’d be very grateful if you could share them with us as they become available.

In particular, we’d love to understand the expected behavior for a public app that is not listed in the Marketplace: when a Super Admin attempts to authorize it and additional conditionally required scopes are requested, which path should we expect? Will the app appear under “Approved apps” through the governance approval flow so the Super Admin can approve the additional scopes there, or is a different behavior expected?

Any insight on this would help us plan our approach.

Thanks again, and I hope you have a great weekend!

7

Hi @developer

The first point I would suggest is to move the app to the Projects-based app platform, as HubSpot is phasing out Legacy Public Apps and has already mentioned this in its official documentation.

For your questions:

You can request all the required scopes during the initial authorization, so additional scopes won’t be needed later, and customers won’t have to reinstall the app.
Approved Apps indicates whether the app has been approved for that particular HubSpot account and which permissions/scopes have been approved. A Super Admin can generally manage this approval.
For a clearer picture of your specific case, I would also recommend contacting HubSpot Support, as App Governance behavior can vary by account.

8

Hi @developer and thanks for your reply!

Thanks also @GRajput for your help!

To clarify the expected behavior for non-marketplace public apps under App Governance:

Yes, non-marketplace public apps do appear under the “Approved apps” tab on governance-enrolled portals. App Governance applies to all OAuth-based apps, not just marketplace-listed ones. When a Super Admin completes the initial authorization for your app, a governance record is created and the app appears under the “Approved apps” tab. The scopes selected during that initial install become the approved scope set for your account.

For additional conditional scopes during re-authorization: The current behavior is that conditional scopes (sent via scope=) that have not been pre-approved will block the authorization entirely, unlike optional scopes (sent via optional_scope=), which appear as toggleable checkboxes on the consent screen. There are no toggles for conditional scopes on the OAuth consent screen. The Super Admin must pre-approve them under Settings → Integrations → Connected Apps → Approved apps → Manage access before the re-auth can succeed.

So, regarding the behavior you’re experiencing, where re-authorization with additional conditional scopes fails instead of allowing approval on the consent screen, the team is actively working on a fix to allow Super Admins to configure governance permissions directly during the OAuth install/re-auth flow, which would restore the additive re-authorization experience. We’ll share updates via the public changelog as they become available.

Why your app appears under “Approved apps” for some accounts but not others: This depends on whether the account is enrolled in App Governance and whether a governance record has been created (i.e., a Super Admin has completed at least one authorization). Accounts not yet governance-enrolled won’t show the “Approved apps” tab at all.

Here is the recommended approach for your iPaaS use case: Until the fix ships, please continue requesting the full scope set on every authorization (PUT semantics) to avoid hitting the conditional scope block. If a customer is already affected, have the Super Admin pre-approve all conditional scopes in the Approved apps settings before attempting re-authorization.

Let us know if you have any additional questions!

Wishing you a fantastic rest of your week!

Bérangère

This post was created with the assistance of AI tools

9

Hi @Berangere and @GRajput ,

Thank you both very much for your detailed explanations and support. This has helped us understand the behavior much more clearly.

Until the fix is released, if we encounter a similar issue, we will first ask the customer’s Super Admin to check whether the Approved apps tab is available. If the app is listed there, we will ask them to pre-approve the required scopes from the app’s access settings before re-authorizing. If the Approved apps option is not available, we will adjust the requested scope set as a workaround.

We will also start planning our migration from the legacy public app framework to the newer Projects-based app platform.

Thank you again for your help. If we run into any further questions or unexpected behavior, we may reach out again.

Best regards,

10

Hi @developer
You’re always welcome to reach out anytime, whether via message or a quick call. I’ll be happy to assist and support in any way I can.

Thanks!

11

Hi @developer and thanks for the update! Glad the explanation helped clarify the behavior and that you’ve got a workaround in place in the meanwhile.

Please do keep us posted on how it goes, especially as you start planning the migration to the Projects-based app platform. Happy to help if any other questions come up along the way!

Wishing you a wonderful day! :orange_heart:

Bérangère