Invalid scopes: account.user+offline_access

The `account.user` scope is limited to account tokens as described here. 

Are you using the `user token` endpoint (/authorize)?  That endpoint does not recognize this scope and will return this error.  Try "https://lucid.app/oauth2/authorizeAccount" and I believe you will no longer get this failure with those scopes.

@mbowers I am using an /authorizeAccount endpoint. I figured that The search parms which is URL encoded on my end is not being decoded ? If however I replace it manually as account.user+offline_access It works fine 

https://lucid.app/oauth2/authorizeAccount?client_id=dummy&state=dummy&redirect_uri=https%3A%2F%2Flucid.app%2Foauth2%2Fclients%dummy%2Fredirect&scope=account.user%2Boffline_access

Thanks I understand your question now. In my testing %2B also did not work which I would expect it to. However I did have success with %20 as "space delimiting" is commonly used with OAuth2 scopes. Hopefully your tool will allow you to provide a space.

Let me know if that does not work. In the meantime l'll submit a bug as %2B should function correctly.

That worked thanks @michael b101

Hi @Michael B101 I have developer access to a lucid account, is there any way to generate an account token since I want to use  List Users API 

Hi ​@Michael B I have developer access to a lucid account, still I’m getting the same error even though I’m passing the correct authorize url. 

Investigating now.

I believe what you are running into now is a mix of scopes that are `user-token` only and `account-token` only.  I see `teams:admin` in your scopes list, but that can not be granted at the account level. It is a `user-token` only scope.

If you need to call endpoints that require different types of scopes, you’ll need to grant two tokens. An `account token` to be used for endpoints that act on the account level, and `user token` for endpoints other endpoints.

I recognize that the current state of token confusion in our API is unfortunate. As we have developed new endpoints, we have tried to avoid requiring `account tokens` as much as possible to avoid this scenario. But, they have one very big advantage of `user tokens`.  Account tokens are not affected by the permission of the user that initially granted it. Meaning, if you grant an account token to do some important task, that task will not break if you lose access to administrative features. A great example is `audit logs`, where a company will setup tasks to pull and store that information that must continue to work long after those who set it up move on.

To help with this problem, when creating new endpoints that have administrative use, we have included a `Lucid-Request-As`: admin header to enable the endpoint to accept a `user-token` with administrative privileges. This token will still no longer work if the granting user loses that access, but if that’s not a concern you won’t have to grant two tokens.

I believe you are wanting to call the LIST Users endpoint which does not currently have this option. However, that is under development and I expect will be available within the next few weeks. That would allow you to call the endpoint without needing to generate an Account token.  

Let me know all the endpoints you are trying to hit, and I can confirm they all will be `user token` endpoints when this work completes soon.

Thanks for the detailed explanation, that makes things much clearer.

I’m currently working with the following operations:

• Users: Create, Read, and List

• Teams: All endpoint operations

Appreciate your help!

https://developer.lucid.co/reference/listteams highlights the changes to https://developer.lucid.co/reference/listusers that are under development. Just as you can use a `user-token` and include the `Lucid-Request-As` header with LIST Teams to be an admin, you will be able to call LIST Users as an admin.

One difference will be that LIST Teams has both a `admin` and `non-admin` version. LIST Users with a `user-token` will be `admin` only.  I do not have a good estimate of when this change will be available, as its competing against a number of high prioroity projects. But, it will be completed in relatively short order.

Thanks for the detailed explanation..