DocCheck Login documentation
⌘ K

# Changes in your system

Overview

After checking the migrated login clients in DocCheck Access, adapt and test the implementation in your own system.

# Test environment

Set up a test environment before replacing the existing implementation.

Use the data from DocCheck Access:

  • Login button HTML
  • Login button script tag
  • Login Client ID
  • Login Client Secret

You can collect and share these values via Share Data in the Button Configurator.

# Replace the login client implementation

Replace the previous implementation with the new login button and script code from DocCheck Access.

Even if your old implementation already used a DocCheck login button from CReaM, that button must be replaced in your application with the new login button from DocCheck Access.

For each migrated login client, verify that your application uses:

  • the new Login Client ID
  • the new Login Client Secret
  • the current button markup
  • the current script tag

# OAuth2 adjustments

Check your OAuth2 logic and replace the legacy endpoint URLs.

Use the new endpoints:

Endpoint URL
Authorization endpoint https://auth.doccheck.com/{language}/authorize
Access token endpoint https://auth.doccheck.com/token
User data endpoint https://auth.doccheck.com/api/users/data

For the complete endpoint overview, see Endpoint overview.

# Examples, templates, and endpoint tests

Additional resources are available for implementation, user-flow understanding, and endpoint tests:

  • Demo Project: example application to understand user flows and see what an implementation can look like.
  • Postman collection: collection for testing the endpoints with your own login client.
  • PHP provider: code example or template for a DocCheck auth flow in PHP.
  • Mobile login: React Native example or template for a DocCheck auth flow in mobile applications.

# Routing changes

Legacy server-side routing by DocCheck is no longer used in the new system.

If your old implementation depended on routing by profession, country, language, or custom URL parameters, move this logic into your own application:

  • Use the state parameter to pass all required parameters through the login.
  • Resolve the returned state value in your application after login.
  • For routing based on user data, request the required scopes and evaluate the returned data from the User data endpoint.

Important

Parameter passthrough is only supported via state and is available starting with Economy. Do not pass personal data in state or redirect_uri.

# User data and scope mapping

Compare the old and new user data payloads and update all dependencies in your application.

Important changes include:

  • unique_id remains stable for real users.
  • New test users and company passwords use the same format as the previous unique ID.
  • ID mappings have changed for country_id, profession_id, and discipline_id.
  • activity_id is new.

For mapping details and payload examples, see Data mapping & payload.

# Test and replace

Before going live:

  1. Test the new login button in your test environment.
  2. Test OAuth2 token exchange and user data retrieval.
  3. Test routing and state handling, if used.
  4. Test with new test users.
  5. Test the endpoints with the Postman collection, if needed.
  6. Compare returned user data against your application requirements.
  7. Replace the old implementation after all checks are successful.
ON THIS PAGE
Test environment
Replace the login client implementation
OAuth2 adjustments
Examples, templates, and endpoint tests
Routing changes
User data and scope mapping
Test and replace
Related topics