API Operational Guide

Default Mode: Visual View

When a standard GET request is triggered without specific filtering query arguments, the engine executes full resolution and serves a comprehensive graphical interface context directly to the browser.

Operational Features

• Assembles all multi-layered JSON attributes automatically into a responsive dashboard template structure.
• Renders verified corporate credentials, manufacturing trails, and cryptographic keys without client-side parsing requirements.

Operational Features in Detail

• Finding the serviceEndpoint: According to the routing logic, the resolver fetches the authoritative W3C DID document. If a JSON structure is discovered, the engine inspects the data layer for a json-file in name (id), type or in a declared serviceEndpoint.
• Exception: Any service entry related to the commercial register (containing commercial-register or com-reg in its id or type) is strictly skipped during this search.
  If no entry explicitly mentions "json", the API falls back to the very first structurally valid service entry available in the array. Commercial register endpoints are still skipped here, as they are reserved for the explicit ?service=com-reg query mode. If no service endpoint matches these criteria, the API aborts and throws an HTTP 404 error.
• Deep Inspection and UI Redirection: Once the primary data endpoint URL is determined (e.g., your legalentity.json or a dpp.json), the API performs a server-side background request:
  • Fetches the JSON Payload: It performs a GET request to the extracted endpoint URL.
  • Evaluates the renderMethod: It parses the returned JSON object and looks for a renderMethod block on the root level (or nested inside credentialSubject.renderMethod).
  • Executes an HTTP 303 Redirect: If a renderMethod is found: The API extracts the template identifier/path (e.g., ./index.html). If it's a relative path, it resolves it relative to the JSON file's directory. The browser is then instantly redirected via an "HTTP 303 See Other" response to this visual presentation interface. If no renderMethod exists (or the endpoint fails): The API uses the raw data serviceEndpoint URL itself as an ultimate fallback and redirects the user's browser directly there.

Typical Use Cases

• Physical consumer interactions (e.g., scanning a physical product QR code leading to the resolver endpoint).
• Direct browser deep-linking into specific identity entries or active Digital Product Passports (DPP).

Parameter: did-only (W3C DID Document)

Appends the isolation condition to request raw cryptographic definitions. When activated, the resolver intercepts the normal rendering pipeline and provides strictly the verified root W3C DID document resource format.

Execution Architecture & Flow

Typical Use Cases

• Automated validation systems verifying public key indices for credential signature evaluations.
• External W3C-compliant decentralized clients checking root controller configurations directly.

Parameter: dpp-only

Isolates the query parameter target payload towards supply chain and production accountability certificates. It bypasses metadata layers and returns exclusively the standardized Product Passport validation manifest block.

Execution Architecture & Flow

Typical Use Cases

• Custom retail scanning terminals pulling item processing footprints and materials metrics into localized inventory views.
• Supply chain tracing software evaluating logistics and environmental criteria against regulatory frameworks.

Parameter: com-reg

Triggers the dedicated authorization route, piping the browser environment directly to the verified company registry source document or storage PDF.

Execution Architecture & Flow

Typical Use Cases

• Instant official compliance verification for anti-money laundering (AML) and Know Your Business (KYB) checks.
• Auditors and supply chain inspectors requesting legally binding trade register proofs linked directly to a decentralized identity.

Usage via Web Interface

The system homepage features an interactive search form which sends data via a standard POST payload (handling form inputs matching the did parameter). The application sanitizes the input string, handles potential trailing whitespaces, and runs Visual View evaluation to immediately redirect users to the visual asset dashboard.