get Auth token with AppKey and Appsecret error

Dropbox is no longer offering the option for creating new long-lived access tokens. Dropbox is switching to only issuing short-lived access tokens (and optional refresh tokens) instead of long-lived access tokens. You can find more information on this migration here.

Apps can still get long-term access by requesting "offline" access though, in which case the app receives a "refresh token" that can be used to retrieve new short-lived access tokens as needed, without further manual user intervention (that is, once the user authorizes the app once, they don't need to authorize the app in their browser again). You can find more information in the OAuth Guide and authorization documentation. There's a basic outline of processing this flow in this blog post which may serve as a useful example.

While short-lived access tokens are temporary, refresh tokens are long-lived and don't expire automatically, like the previous long-lived access tokens. So, you can store and re-use refresh tokens like you may have previously done with long-lived access tokens. For reference, both with the process for previous long-lived access tokens and new short-lived access tokens/refresh tokens, note the "authorization codes" have and continue to be temporary single-use codes used during the authorization process.

As for examples, the HTTP documentation has examples shown in curl, but you can translate that for whatever platform you need. And for prototyping and trying out specific API calls, the API v2 Explorer can be helpful. It can even show you how the request would be formatted in multiple contexts, such as in Python or raw HTTP, if you click "Show Code". There are also official SDKs listed here, which each come with some examples.

Also, "oauth1_token" and "oauth1_token_secret" are parameter names for use with /2/auth/token/from_oauth1 only. That is only needed if you have previous OAuth 1 access tokens from the now-retired API v1 and need to convert them to OAuth 2 for API v2. It sounds like that's not the case in your scenario though so you shouldn't be using "oauth1_token" and "oauth1_token_secret" or /2/auth/token/from_oauth1.