System Configuration
Last updated
Last updated
Appmixer offers a variety of system configuration options for advanced use cases, allowing you to finely tune the behavior of its underlying workflow and integration engine. To access and set these configuration options, navigate through the Appmixer Backoffice interface to the "System -> System Configuration" page.
Please be aware that certain configuration changes may not take immediate effect without restarting the Appmixer engine. For customers with a Self-Managed Appmixer installation, restarting the engine can be done at your convenience to apply the new settings. For those with a hosted Appmixer tenant, it's advisable to reach out to our support team at support@appmixer.com. Our team can provide guidance on how to effectively set these configuration options and assist with any necessary engine restarts to ensure your configurations are applied as intended.
Below is a list of available configuration options, accompanied by a brief explanation for each and their default values. These defaults are used by Appmixer in instances where no specific value is provided:
API_USER_CREATE_SCOPE
By default, the POST /user API is open to enable the sign-in feature for everyone. This option can restrict the access to this endpoint. It takes a list of scopes (comma-separated). If the value is not null, then a JWT token has to be used to call this API. Typically, the value is set to admin.
null
APP_NAME
This will for example appear in the head title of a sign-in popup for Api Key services.
Appmixer
AUTH_HUB_AUTOMATIC
If the auth-hub system plugin is on and this value is true, all OAuth requests for unconfigured services will go through the Authentication Hub. It means that if you install Slack, for example, and do not configure the clientId and clientSecret the engine will use the Appmixer Authentication Hub for Slack authorization.
true
DEFAULT_USER_VENDOR
Vendor assigned to newly created users.
No value
AUTH_POPUP_TIMEOUT_ERR
How many seconds before automatically closing the Connecting Account Failed popup window.
5
BROKER_MESSAGE_ACK_TIMEOUT
Timeout for message processing.
1500000
COMPONENT_FACTORY_TIMEOUT
An attempt to create a component will fail after this timeout.
300000
COMPONENT_RECEIVE_TIMEOUT
A message will be retried if the receive() function does not return within this timeout.
1380000
LIMIT_FLOW_UPDATE_BYTES
The max size in bytes of a flow descriptor to be able to be saved.
2097152
LIMIT_CC_ARCHIVE_MAX_BYTES
Maximum size in bytes for custom components.
10485760
LIMIT_WEBHOOK_BYTES
Maximum payload size in bytes for webhook components.
1048576
WEBHOOK_REQUEST_TIMEOUT
Timeout in milliseconds for webhook component requests.
10000
LIMIT_COMPONENT_STATIC_CALL_MAX_BYTES
Maximum size in bytes of the payload for component static calls.
104857600
PUBLIC_FILES_PREFIX
Public files (needed usually for domain verification) can be served from different paths. Path prefixes have to be separated by :
RETRY_INIT_EXP
In case of an error, message for a Component is rescheduled for another attempt. Backoff strategy is used. This retryInitExpiration is the initial value for the backoff, it says after how many milliseconds the first attempt after a failure is going to happen.
60000
RETRY_MAX_COUNT
How many times does the engine try to process the message before rejecting it forever (and moving into the Unprocessed Messages collection).
30
RETRY_MAX_EXP
Maximum interval in milliseconds between retry attempts.
3600000
DISPATCHER_PREFETCH_COUNT
The maximum number of Rabbit messages being dispatched at the same time.
500
INPUT_QUEUE_PREFETCH_COUNT
The maximum number of outgoing Rabbit messages waiting for aknowledgement at the time in the Input Queue. Subsequent incoming messages will not be sent until pending messages are aknowledged.
300
WEBHOOK_PREFETCH_COUNT
This is for webhooks from Appmixer to registered URLs. This is the amount of webhook messages that will be processing at a time.
50
WEBHOOK_RETRY_COUNT
Number of times that Appmixer will retry sending a webhook. Applies for all webhooks.
20
WEBHOOK_RETRY_INTERVAL
Initial interval in milliseconds for retries. Subsequent retries will take longer (multiplied by an internal factor).
30000
WEBHOOK_RETRY_MAX
Maximum interval in milliseconds between retries.
1800000
WEBHOOK_USER_CREATED
URL that will be called when new user is created (sign-up).
No value
WEBHOOK_FLOW_COMPONENT_ERROR
URL that will be called when a running flow encounters an error.
No value
WEBHOOK_FLOW_COMPONENT_ERROR_INCLUDE_QUOTA
Include quota errors among the errors sent to the registered webhook URL.
false
WEBHOOK_FLOW_COMPONENT_ERROR_INCLUDE_RETRY
Include retry attempts among the errors sent to the registered webhook URL. If false, the error will be sent, when all 30 attempts to process a message fail. If true, every failed attempt will be sent.
false
WEBHOOK_FLOW_STOPPED
URL that will be called when a flow is stopped due to an incompatible module upgrade.
No value
STRICT_COOKIES
If set to true, the engine will reject any incoming HTTP requests that have cookies that don't comply with the HTTP cookies RFC specification.
false
GARBAGE_COLLECTOR_CONTINUITY_SCOPES_TTL
The maximum time in days before continuity scopes are garbage collected. A continuity scope is a state of a flow including data from the flow runtime needed to continue the flow from a certain component onwards. For example, the Plivo.SendSMSAndWaitForReply sends an SMS and waits for an event (webhook) from Plivo that contains an SMS with a reply. The continuity scope contains all the data needed to continue the flow at a later time (when the webhook from Plivo is received which can take hours to days.
100
