We use authentication based on the OAuth 2.0 standard.

As a Partner, you will receive client_id and client_secret from Bitpanda. To make the exchange secure, we will ask you to share a public GPG/PGP key with Bitpanda, as well as an email address for future technical communication. Bitpanda will send back your client_id and client_secret, which is encrypted with the key, shared in the previous step.

With the provided client_id and client_secret you can issue one or more initial Refresh tokens.

Refresh tokens can not be used to call the endpoints. They can be used only for requesting a short-lived Access Token and a new Refresh Token.

For the API authorization you will need an active Access Token, which can be issued by using a valid Refresh token.

Each White Label API request must contain an authorization header (in the format below) to make a call: Authorization: Bearer [YourAccessTokenHere].

Access tokens have a limited lifetime (currently set to 10 minutes). If your application needs access to a Whitelabel API beyond the lifetime of a single access token, it can obtain a new Access token by using a valid Refresh token.

To get a new Access Token you will need a valid Refresh token. When a new Access Token is claimed, it will be provided along with a new Refresh Token. When you receive the new set consisting of access - refresh token:

• the Refresh token, which you used in the request, will be invalidated.
• The “old” Access token will not be invalidated when you receive the new one. It will become inactive only after its TTL lapses. In this way you can have a smooth transition between the old and the new access token, when doing API requests

Refresh tokens also have a relatively short lifespan, currently set to 24h.

A refresh token will become invalid either

• 24h after its issuing
• when an access token is renewed by using an active refresh token
• In case you initiate refresh token revocation