Web-API Bearer Tokens and App Features

Upon launching the Web Application, a dedicated record in the hyp_Web API Tokens table is automatically created for a new username, or updated if it already exists, as part of the initialization process.
From this page, you can manually set the lifespan of each bearer token (per Web-App instance), manage security policies, and enable or disable specific features.

Server WebAPI Tokens
Field Name Description
Hyper User Name Readonly field: This field displays the username saved by the Web-App engine during its first launch.
The username is initially defined in the server's INI file during installation.
If this exact username is also configured in the system’s "Employees and Users" module, the Web-App will inherit that user's specific access permissions and interface language, as detailed in the installation guide.
Created On UTC Readonly field: The exact date and time (in UTC) when the record was created.
Domain Address Readonly field: Each Web-App requires a unique Domain or IP Address. This field displays the domain name assigned to the application on the server.
Domain Purpose Readonly field: Each Web-App is assigned a "Purpose" that dictates its role and operating mode for the bound domain address.
This setting is defined on the server side (via the .ini file), as explained in the Web Application Installation Guide.
Possible options include:
  • Default Web Portal
  • API mode (no HTML)
  • Data Port (only)
  • Database Connection (JSON)
Max Tenants Readonly field: The amount of concurrent entities (client, hyper user) that this Domain is allowed to hold in memory. (value copied from the .ini file)
Max Threads Readonly field: The amount of requests that can be processed in parallel. Each thread can hold another request in it's queue. (value copied from the .ini file)
Generated Token Life in Hours Defines the default lifespan for newly generated Access Tokens.
The initial default value is 1 hour. It can be adjusted manually by the System Admin (valid range: 1 to 8,760 hours).
Modifying this field automatically recalculates the "Access Until UTC" field. Upon saving, the Web-App immediately applies the new policy.
Access Until UTC This field sets the explicit expiration date and time for the current Access Token, overriding the general duration defined above.
It can be set manually or calculated automatically based on the "Generated Token Life in Hours" value. Changes take effect immediately upon saving.
Last Access Token Refresh UTC Readonly field: The timestamp indicating the last time the Access Token was successfully regenerated, either via an API call (Refresh Token) or manually through the "Regenerate Tokens" button.
Max Posts per IP per Minute Limits the number of API requests permitted from a single IP address per minute, providing fundamental protection against abuse and Denial of Service (DoS) flooding.
The default threshold is 20 posts per minute. If this threshold is exceeded, the server's protection mechanism will temporarily block further requests from that IP.
You can increase this limit, though we strongly advise against exceeding 500 posts per minute. If left empty, the Web-App assigns a default value based on its designated "Purpose".
Session Timeout # Minutes The duration of inactivity (in minutes) after which an idle user's session will automatically expire.
IP v4 Whitelist An optional security layer for explicitly permitting specific IP addresses.
If left empty, the Web-App will accept requests from any IP address globally. If populated, it acts as a strict firewall, blocking all traffic except from the IPs listed here.
Domain Enabled Modules When left empty, the Web-App loads its standard modules based on its configured "Purpose".
To load additional or custom modules, enter the exact name of each module on a separate line.
A manual restart of the Web-App is required after modifying this list. Contact support to determine if specific custom modules are required for your implementation.
Block These Functions Use this field to restrict specific operations for both API and HTML modes !
Enter the exact API function names you wish to block from execution on this specific application (one function name per line).
Keep Alive UTC Readonly field: The timestamp of the latest automated "Keep Alive" signal received from the Web-App instance.
Last Trans UTC Readonly field: The timestamp of the last data transaction or activity successfully executed using this token.

The tokens are stored inside the table.

Field Name Description
Access Token A 120-character encrypted string serving as the primary bearer token. It is used to authenticate incoming API requests for the specified Domain Address.
Click the icon next to the field to copy the token to your clipboard.
Prev Access Token This system-managed field temporarily stores the previous Access Token immediately after a token regeneration.
It provides a crucial 3-minute grace period to ensure that ongoing or delayed network requests using the old token complete successfully without interruption.
Refresh Token A 200-character string used exclusively to request a new Access Token. This token never expires automatically, but it is regenerated during an API "Refresh Token" request or when the manual "Regenerate Tokens" button is triggered.
Click the icon next to the field to copy the token to your clipboard.

Action Buttons

Below is an explanation of the actionable buttons located at the bottom of the configuration page:
Save Settings Save Settings Saves changes made to fields such as [Access Until UTC] and [Generated Token Life in Hours].
It immediately broadcasts a refresh signal to the target Web-App, commanding it to reload the updated token parameters into active memory.
Delete Domain Delete Domain Permanently deletes the selected domain configuration row from the tokens table (this action is independent of the 'Save' button).
It instantly sends a refresh command to the API system to purge the domain from active memory.
Regenerate Tokens Regenerate (both) Tokens This process manually revokes and creates new authentication credentials by performing the following steps:
  1. Backs up the current
    [Access Token]
    into the
    [Prev Access Token]
    field.
  2. Generates entirely new strings for both the
    [Access Token]
    and the
    [Refresh Token]
    .
  3. Updates the
    [Last Access Token Refresh UTC]
    and calculates a new
    [Access Until UTC]
    timestamp.
  4. Broadcasts a refresh message to the Web-App, forcing it to immediately recognize the newly generated tokens.