Legacy vs New

Overview

This page summarizes the key changes from the legacy DocCheck CReaM login world to the new DocCheck Access system.

Important: DocCheck CReaM and DocCheck Access are technically separate systems. Account and client settings were transferred as far as possible. Because DocCheck Access offers additional configuration options, all transferred settings should be checked and completed in the new system if needed.

General changes

Area	Legacy system	New system
System	DocCheck CReaM	DocCheck Access as a technically separate new system
Integration	iFrame, legacy implementation, or CReaM login button	Login button from DocCheck Access with fullscreen login window
Client data	Existing CReaM client data	New Login Client IDs and client secrets in DocCheck Access; transferred settings must be checked and completed if needed
Environments	Less strict separation	Clear separation between production and development clients
Data sharing	Manual transfer of integration data	Secure sharing via Share Data in DocCheck Access
Testing	Company/test passwords	Company passwords & test users must be created again
Administration	Existing CReaM admins	No automatic migration of CReaM admins; colleagues who need access must be invited or created in DocCheck Access. The new roles and permissions system includes Company Owner, Admin, Editor, and Reader.

Note on admins, company passwords, and test users

Admins, company passwords, and test users are intentionally not migrated automatically to the new system. Some of this data was very old, so the migration uses a clean cut for security reasons.

Use the migration to recreate only the company passwords and test users that are still required. Also invite only the colleagues who need access to DocCheck Access settings or booking options. With the new roles and permissions system, you can define who receives which permissions.

Technical changes

The legacy iframe and the previous CReaM login button are replaced by the new login button from DocCheck Access. The login flow is based on OAuth2 and uses new endpoint URLs.

Endpoint	New 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

The authorization endpoint uses a language prefix, for example /en/, /de/, /fr/, /it/, /es/, or /nl/. The selected language also affects the login and consent flow.

For implementation steps, see Changes in your system and the Endpoint overview.

Parameter, routing, and security

• All parameters that need to be passed through the login must be transported via the state parameter.
• state is available starting with Economy and is not available for Basic clients.
• All parameters must be passed through the login via the state parameter.
• Server-side routing by DocCheck is no longer used in the new system.
• Routing by profession, country, language, or campaign logic must be handled in your own application.
• Use HTTPS only.
• Do not pass personal data in state or redirect_uri.

Changes by license

Basic

• The iframe is replaced by the login button.
• In DocCheck Access, even free Basic clients can optionally use OAuth2 Authorization Code → Access Token as an additional authorization step.
• The access token confirms successful authentication only and is not used to retrieve user data.
• The state parameter is not available for Basic clients.

Economy

• state is the standard way to pass all required parameters through the login.
• Selected user data can be requested via scopes, for example unique_id, profession, country, and language.
• A configurable consent form is used for requested scopes.
• Mandatory scopes can be configured.
• Basic login statistics are available.
• Routing logic must be implemented customer-side by evaluating state and/or returned user data.

Business

• Business includes Economy features and adds extended scopes for personal data, such as name, email, address, and occupation details.
• Personal data is retrieved via OAuth2 after consent.
• Email domain and IP whitelists can be managed in self-service.
• Extended statistics include consent status and logins by profession.

Data model and payload changes

The user data payload changed between the legacy and new systems. Important examples:

• uniquekey → unique_id
• address_name_first / address_name_last → first_name / last_name
• address_postal_code → area_code
• address_country_iso → country_iso_code
• activity_id is new
• user_language is new
• address_gender, address_name_title, and occupation_profession_parent_id are no longer returned
• ID mappings changed for country_id, profession_id, and discipline_id

For complete field mapping, payload examples, and ID mapping notes, see Data mapping & payload.

Summary table

Feature	Legacy system	DocCheck Access
Login UI	iFrame / legacy implementation / CReaM login button	DocCheck Access login button + fullscreen login window
Authentication	Legacy flow / OAuth2 depending on setup	OAuth2 Authorization Code Flow
Client IDs	Existing CReaM IDs	New Login Client IDs; check and complete configuration
Client secrets	Previous secrets / not available depending on setup	New Login Client Secrets in DocCheck Access
Endpoint domains	Legacy endpoints	New endpoint domains under https://auth.doccheck.com
Environments	Less strict separation	Separate production and development clients
Parameter passthrough	URL append patterns	Via state only, starting with Economy
Routing	Server-side routing by DocCheck	Customer-side logic via state and/or user data
User data	Legacy payload	Scope-based user data endpoint after consent
Consent	Legacy Personal form logic	Configurable consent form per login client
Test setup	Company/test passwords	Create company passwords & test users again
Whitelisting	Manual via support	Self-service in Business