> ## Documentation Index
> Fetch the complete documentation index at: https://developer.mindbridge.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Read Async Result
> Read an existing async result, identified by its ID.
### Permissions
This endpoint inherits the permissions from the target entity in scope. For example, if the async result represents an **analysis source**,
then the requesting token must contain the permission: `api.analysis-sources.read`.
## OpenAPI
````yaml /openapi_1.8.4.json get /v1/async-results/{asyncResultId}
openapi: 3.1.0
info:
title: MindBridge API
description: >
The MindBridge API is an HTTP REST API that provides access to MindBridge
entities and processes. Request and response bodies are
generally JSON formatted, with some exceptions.
## Endpoint model
Endpoints are structured in a standard way:
### Create
`POST /{entityName}` - Creates an entity with the properties specified in
the request body.
### Read
`GET /{entityName}/{entityId}` – Reads the entity identified by the ID.
### Update
`PUT /{entityName}/{entityId}` – Updates the entity identified by the ID
with the content of the request body.
Every time an entity is saved, the `version` property is incremented. To
prevent multiple calls from overwriting each other's changes,
the `version` property in the updated request body must match the latest
version on MindBridge's servers.
### Delete
`DELETE /{entityName}/{entityId}` – Deletes the entity identified by the ID.
### Query
`POST /{entityName}/query` – Performs a paged query of the entity
collection.
## Entity model
All endpoint requests and responses for a given entity use the same model
structure, with some fields being either read-only or editable
depending on the method. If a property is not editable for the endpoint in
question, it will be ignored.
For example, if the following organization entity body is used with the
`Create Organization` endpoint, then the `id` property will be
ignored and a new organization will be created with a new id and "New
organization" as the name.
```json
{
"id": "4b8360d00000000000000001",
"name": "New organization"
}
```
Using this approach, an entity can be created or updated using the same
model read from a read entity call, as read-only fields will not be
overwritten by changes made to the _create_ or _update_ body.
If a property that is not present on the model is included in a create or
update request, then the request body will be considered invalid
and an error will be returned.
## MindBridge Query Language
### Overview
MindBridge Query Language (QL) is the standard unified query language used
to interact with all the underlying data tables and
collections within MindBridge. This query language has been extended to the
MindBridge API, which uses this syntax for all `/query`
endpoints within the API, as well as several other endpoints.
### Syntax
The query is expressed as a JSON object. The example below looks for values
equal to 10000 in the `credit` column.
```json
{
"credit": {
"$eq": 10000
}
}
```
Above, `$eq` is the equality operator. Other operators are listed below. As
a shortcut for equality, you can specify the value directly.
```json
{
"credit": 10000
}
```
In order to conform to the syntax of a valid JSON object, all operators and
fields must be enclosed in quotes. For more details on the
JSON language, refer to [json.org](https://json.org).
Logical `AND` and `OR` conditions are available. If you want to specify two
columns, the conditions can be combined with `$and`.
```json
{
"$and": [
{
"account": {
"$eq": "1023345"
}
},
{
"risk": {
"$gte": 5000
}
}
]
}
```
#### Simplified Syntax
The example `$and` query above can be simplified using the syntax seen
below.
```json
{
"account": {
"$eq": "1023345"
},
"risk": {
"$gte": 5000
}
}
```
You can combine `$or` and `$and` to build up a more complex structure, such
as the one seen below, which combines all the techniques
seen so far.
```json
{
"risk": {
"$gte": 5000,
"$lt": 7000
},
"$or": [
{
"transaction": {
"$iprefix": "ABC1"
}
},
{
"transaction": {
"$iprefix": "ABC2"
}
}
],
"$and": [
{
"source": {
"$ne": "MA"
}
},
{
"source": {
"$iprefix": "M"
}
}
]
}
```
You can use two operators on the same column at the same time:
```json
{
"credit": {
"$gte": 1000,
"$lt": 10000
}
}
```
#### Unique Names
Every field in a JSON object or sub-object must be **unique**. The following
is not valid because `source` appears twice at the top level.
```json
{
"source": {
"$ne": "MA"
},
"source": {
"$ne": "MB"
}
}
```
Instead, wrap it in `$and`:
```json
{
"$and": [
{
"source": {
"$ne": "MA"
}
},
{
"source": {
"$ne": "MB"
}
}
]
}
```
Or use another operator like `$nin`:
```json
{
"source": {
"$nin": [
"MA",
"MB"
]
}
}
```
You can use two operators on the same column at the same time:
```json
{
"credit": {
"$gte": 1000,
"$lt": 10000
}
}
```
### Column Operators
**Column operators** apply a filter to a specific column.
| Description |
Description
| Column
Types
| Field
Conditions
|
|--------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------|
| `$eq` | Tests if the value in the column **is identical** to the
literal
value.
| STRING
DATE_TIME
INT32
INT64
FLOAT32
FLOAT64
MONEY_100
PERCENTAGE_FIXED_POINT
OBJECT_ID
| case-insensitive on STRING values
`equalitySearch` must be
true |
| `$ne` | Tests if the value in the column **is not identical** to
the literal
value.
|
STRING
DATE_TIME
INT32
INT64
FLOAT32
FLOAT64
MONEY_100
PERCENTAGE_FIXED_POINT
OBJECT_ID
| case-insensitive on STRING values
`equalitySearch` must be
true |
| `$gt` | Tests if the value in the column is **greater than** the
literal
value.
|
STRING
DATE_TIME
INT32
INT64
FLOAT32
FLOAT64
MONEY_100
PERCENTAGE_FIXED_POINT
OBJECT_ID
| case-insensitive on STRING values
`rangeSearch` must be
true |
| `$gte` | Tests if the value in the column is **greater than or
equal** to the literal
value.
|
STRING
DATE_TIME
INT32
INT64
FLOAT32
FLOAT64
MONEY_100
PERCENTAGE_FIXED_POINT
OBJECT_ID
| case-insensitive on STRING values
`rangeSearch` must be
true |
| `$lt` | Tests if the value in the column is **less than** the
literal
value.
|
STRING
DATE_TIME
INT32
INT64
FLOAT32
FLOAT64
MONEY_100
PERCENTAGE_FIXED_POINT
OBJECT_ID
| case-insensitive on STRING values
`rangeSearch` must be
true |
| `$lte` | Tests if the value in the column is **less than or equal**
to the literal
value.
|
STRING
DATE_TIME
INT32
INT64
FLOAT32
FLOAT64
MONEY_100
PERCENTAGE_FIXED_POINT
OBJECT_ID
| case-insensitive on STRING values
`rangeSearch` must be
true |
| `$contains` | Tests if an array **contains** a literal value.
For
example, given a transaction with entries from accounts 12345 and 23456, the
following query on the `gl_journal_tx` data table would match the
transaction:
```{ "accounts": { "$contains": "12345" }
}```
|
ARRAY_STRINGS
| case-insensitive on STRING values
`containsSearch` must be
true |
| `$ncontains` | Tests if an array **does not contain** a literal
value.
|
ARRAY_STRINGS
| case-insensitive on STRING values
`containsSearch` must be
true |
| `$in` | Tests if a column is equal to one of the values in an array
of
literals.
|
STRING
DATE_TIME
INT32
INT64
FLOAT32
FLOAT64
MONEY_100
PERCENTAGE_FIXED_POINT
OBJECT_ID
| case-insensitive on STRING values
`equalitySearch` must be
true |
| `$nin` | Tests if a column is **not equal** to any values in an
array of
literals.
|
STRING
DATE_TIME
INT32
INT64
FLOAT32
FLOAT64
MONEY_100
PERCENTAGE_FIXED_POINT
OBJECT_ID
| case-insensitive on STRING values
`equalitySearch` must be
true |
| `$flags` | Accepts an object with one or more keys with boolean
values. Tests if the flags (keys) match the values.
For example, to
search for entries that triggered the [2 Digit
Benford](https://support.mindbridge.ai/hc/en-us/articles/360056059834)
control point, use this query on the `gl_journal_lines` data table.
```{
"cp_failed": {"$flags": { "journal_entry_two_digit_benford": true }}}``` |
BOOLEAN_FLAGS
|
|
| `$isubstr` | Tests if a literal value **matches** the value in the
column. For example, the following query on the `engagements/query`
endpoint will match engagements named "abc", "aBc", and "zabcd".
```{ "name": { "$isubstr": "abc" }
}```
|
STRING
| case-insensitive on STRING
values
`allowCaseInsensitiveSubstringSearch` must be true |
| `$iprefix` | Tests if a literal value **matches** the start of the value
in the column. For example, the following query on the `gl_journal_tx` data
table will match transactions "T1234", "t1234", and "T12345".
```{
"transaction": { "$iprefix": "T1234" }
}```
|
STRING
| case-insensitive on STRING values
`caseInsensitivePrefixSearch` must
be true |
| `$niprefix` | Tests if a literal value **does not match** the start of
the value in the
column.
|
STRING
| case-insensitive on STRING values
`caseInsensitivePrefixSearch` must
be true |
### Root Operators
#### Logical Operators
**Logical operators** allow MindBridge to combine Column Operation queries
to allow for more sophisticated calls.
| Operator | Description
|
|----------|----------------------------------------------------------------|
| `$and` | Tests that **all** contained terms are evaluated to be `true`.
|
| `$or` | Tests that **any** contained terms are evaluated to be `true`.
|
#### Keyword Operators
**Keyword operators** are applied simultaneously to all columns that support
keyword searches. This is controlled by the keywordSearch
attribute associated with the column’s metadata.
| Operator |
Description
|
|-----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `$keyword_prefix` | Performs a case-insensitive prefix search of all
words in the row (operand must be a STRING).
For example, the following
query on the `gl_journal_tx` data table will return transactions with rows
that contain the words **abc** , **abcdef**, or **aBcd** in any column.
```{ "$keyword_prefix": "abc" }``` |
| `$keyword_prefix_not` | Inverted case-insensitive prefix search (operand
must be a
STRING).
|
#### Population Operators
**Population operators** test whether the specified entry is or is not
included within the specified population, identified by its ID. The
population in question must be accessible from the analysis, meaning the
population must be part of the analysis, engagement, or library
that this data table resides in.
| Operator |
Description
|
|-------------------|---------------------------------------------------------------------------------|
| `$population` | Tests that entries are part of the population
specified by the provided ID. |
| `$not_population` | Tests that entries are not part of the population
specified by the provided ID. |
The correct usage of `$population` and `$not_population` is as follows, with
`643eff00ec992f7ec42ed9f7` being a valid population ID:
```json
{
"$population": "643eff00ec992f7ec42ed9f7"
}
```
```json
{
"$not_population": "643eff00ec992f7ec42ed9f7"
}
```
### Data Formats
Because the MindBridge QL is based on JSON, `strings`, `numbers`, and
`booleans` are natively included in the language definition, but
other values require some conversion. The following table describes the
values MindBridge QL accepts in relation to our internal data
structure. The contents of the "Column Type" column (below) represent the
data types supported internally and how they are mapped to the
JSON object structure.
| Column Type |
Format
|
|--------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `STRING` | Value must be a JSON
string.
|
| `DATE_TIME` | A JSON string in ISO8601 date-time format, such
as
**2019-08-10T00:50:00Z**.
|
| `BOOLEAN` | Value must be a JSON boolean (true or
false).
|
| `INT32` | Value must be a JSON number in the range
**[-2^31,
2^31-1]**.
|
| `INT64` | Value must be a JSON number in the range
**[-2^63,
2^63-1]**.
|
| `FLOAT32, FLOAT64` | Value must be a JSON number.
FLOAT32
**[1.2E-38, 3.4E+38]**
FLOAT64 **[2.2E-308,
1.7E+308]**
|
| `MONEY_100` | Currently we express currency values as
integers, essentially multiplying by 100 to store, and dividing by 100 when
displaying the value.
This allows MindBridge to operate with floating
point numbers without loss of precision. Value must be a JSON number in the
range **[-2^63,2^63-1]**. No division by 100 is performed on the actual
data.
For example, in a `MONEY_100` column, such as credit, the
following query on the `gl_journal_lines` data table will find values
greater than 1234.
```{ "credit": { "$gt": 1234 } }``` |
| `PERCENTAGE_FIXED_POINT` | Value must be a JSON number in the range **[0,
10000]** where 10000 means
100%.
|
| `ARRAY_STRINGS` | Value must be an array of JSON
strings.
|
| `OBJECT_ID` | A 12-byte database identifier, represented by a
24-character hexadecimal string. Organizations, engagements, analyses, and
analysis sources all use **OBJECT_ID** for their `id` fields.
For
example,
`6686add55cd5c94147ecebdb`
|
## Rate limiting
**Rate limiting** restricts the number of API calls that can be made to
certain endpoints over a given period of time, and has been applied
to the endpoints indicated below. Once the limit is reached, further calls
to any of these endpoints will fail until the rate limit resets.
These failures will show the HTTP status: `429 Too Many Requests`, along
with a response header: `X-User-Hour-Limit-Remaining`. The
value in the response header represents the number of seconds until the rate
limit resets.
For example, suppose the `POST /users` endpoint has a rate limit of `100`
calls per `1 hour`. If more than 100 requests are made within the
given hour, any subsequent requests would fail and return the error
indicated above.
Since rate limiting is applied tenant-wide, all tokens share the same rate
limit.
### Rate limits
| Name | Reset time remaining header | Limit | Duration
| Endpoints |
|-------------------------|-------------------------------|-------|----------|---------------------------------------------------------------|
| Modify users rate limit | `X-User-Hour-Limit-Remaining` | 100 | 1 hour
| - Create user
- Update user
- Resend activation email |
### Platform-level rate limits
Additional rate limits are applied at the platform level on a per-IP address
basis to protect against potential abuse or client-side
software incidents, and are set high enough that customers should not
encounter them in regular use. Platform-level rate limits will return
the HTTP status `429` with no `X-User-Hour-Limit-Remaining` header, and
requests can be retried after approximately 30 seconds.
contact:
name: MindBridge
url: https://mindbridge.ai
email: developer@mindbridge.ai
version: 1.8.4
servers:
- url: https://{tenant}.mindbridge.ai/api
description: MindBridge API base URL
variables:
tenant:
description: MindBridge tenant (subdomain)
enum:
- test
default: test
security:
- mindbridge-api: []
tags:
- name: Tasks
description: >
**Tasks** are data table transactions or entries that have been added to
the audit plan for further investigation.
x-tag-expanded: 'false'
- name: Account Mappings
description: >
_Account mapping_ aligns your organization's accounts with MindBridge
Account Classification (MAC) codes based on their
nature, ensuring that MindBridge can consistently and effectively analyze
datasets across the engagement.
Before an analysis can be run, all account mappings within the given
engagement must be marked as _Verified_ or _MAC code_.
## Mapping statuses
- **Verified**: Indicates that the account has been mapped to a MAC code
or grouping code _automatically_, and/or was
previously manually verified.
- **Unverified**: Indicates that MindBridge _automatically_ mapped the
account to a lowest level account grouping code
based on the grouping code and/or account description, and should be verified for accuracy before you proceed.
- **MAC code**: When using a MindBridge default library, this indicates
that the imported general ledger file included
a "MAC code" column that accurately reflects the lowest-level MAC code for each account group in the ledger — in this
case, MindBridge uses _direct matching_ to map the accounts.
- **Modified**: Indicates that an account's MAC code was updated when
copied between account groupings — this may happen
if a _different library_ is selected while rolling an analysis forward or duplicating an analysis into a _new
engagement_.
- **Manual**: Indicates that the account mapping was changed manually by a
member of your team.
- **Inferred**: When a less granular grouping code or MAC code is
provided, this indicates that MindBridge has
automatically mapped the account to a Level 3 MAC code based on the provided code and account description, and should
be verified for accuracy before you proceed.
- **Unmapped**: Indicates that the account has not yet been mapped to a
valid MAC code or grouping code.
x-tag-expanded: 'false'
- name: File Manager
description: >
The **file manager** is a secure, centralized holding area designed to
store files related to an engagement. It supports a folder-based
hierarchy, allowing data to be utilized for various purposes. Files stored
in the file manager can be imported into appropriate analysis
sources*.
***Note:** The file manager can hold any number of files, but the analysis
source types available within an engagement are controlled by the
selected library and the analysis types it supports.
x-tag-expanded: 'false'
- name: Engagement Account Groupings
description: >
An **engagement account grouping** is an engagement-level copy of an
account grouping that is generated upon creation of a new
engagement. Subsequent changes made to the original account grouping
and/or its account groups will not be copied into the
engagement account grouping, and vice versa.
x-tag-expanded: 'false'
- name: API Tokens
description: >
**API tokens** are used to authenticate requests made to the MindBridge
API. During creation, each token is assigned permissions that
control the actions it can perform.
API tokens are valid until their expiry date, after which they can no
longer be used. A token may be active for a maximum of 2 years from
the date of creation.
Additionally, API tokens can be configured to limit access to specific IP
addresses or CIDR blocks by setting the `allowedAddresses`
property to a valid IPv4 or IPv6 address, or CIDR range.
## API Token Users
Once an API token is created, an **API Token User** is automatically
created and assigned to the API token. This non-human user account
represents the API token, and any action that the API takes will be
attributed to that user. Because each API Token User is linked to a
unique API token, these accounts cannot be deleted or disabled, except by
deleting the associated API token itself.
x-tag-expanded: 'false'
- name: Async Results
description: >
**Async results** can be used to track the status of asynchronous
background jobs (such as data ingestion) for which results may not be
immediately available. Users can poll these records to view the status of
their requests. Once the requests have been completed, users can
call the relevant entity’s `Read` endpoint to view the results of the job.
### Permissions
The **permissions** needed to access this collection are controlled by the
target data you are attempting to access.
x-tag-expanded: 'false'
- name: Connection Test Results
description: >
**Connection Test Results** represent the outcome of running a
Connection's "Test Connection" operation. The Connection Test Result
is stored as a record containing a message indicating whether the
connection was successful or describing the failure.
#### Cleanup task
A cleanup task is regularly run that will delete Connection Test Results
that are older than 7 days.
x-tag-expanded: 'false'
- name: Task History
description: >
**Task Histories** are the history entries related to an individual task
within the system.
x-tag-expanded: 'false'
- name: Data Transformation
description: >
The **data transformation** endpoint is a collection of data manipulation
techniques that can be performed on file manager files. These
transformations can be applied to one or more files, and typically
generate new files based on specified input configurations.
x-tag-expanded: 'false'
- name: Analysis Source Types
description: >
An **Analysis Source Type** describes the features applied when importing
an analysis source, such as the effective date
range, transaction ID selection, etc., as well as relevant MindBridge
column definitions. These features determine which
steps occur during the analysis source import process.
### Alternative MindBridge field names for non-MAC account groupings
When using a non-MAC based account grouping, some MindBridge fields use a
different name (for example, `mac_code`
becomes `custom_code`). This is identified by the
`mindbridgeFieldNameForNonMacGroupings` field, which describes which
MindBridge field name to use instead.
Additionally, when using a non-MAC based account grouping, some fields may
become required. This is indicated by
the `requiredForNonMacGroupings` field, which is set for all fields that
specify
a `mindbridgeFieldNameForNonMacGroupings` value.
x-tag-expanded: 'false'
- name: Data Tables
description: >
After running the analysis, the **data table** provides results details
about the imported financial data for the
current period.
### Logical names and types
Data tables types can be identified by either their `logicalName` or
`type` field, depending on the data table, and can
be queried accordingly using the following fields:
| Table |
Field | Value |
|------------------------------------------------------------|---------------|------------------------------------|
| General Ledger Entries |
`logicalName` | `gl_journal_lines` |
| General Ledger Transactions |
`logicalName` | `gl_journal_tx` |
| Monetary Flows |
`type` | `flows_compact` |
| Accounts Payable Entries |
`logicalName` | `ap_detail_entries` |
| Accounts Receivable Entries |
`logicalName` | `ar_detail_entries` |
| Accounts Payable: End of Period Outstanding Payable |
`logicalName` | `ap_detail_union_open_payables` |
| Accounts Receivable: End of Period Outstanding Receivables |
`logicalName` | `ar_detail_union_open_receivables` |
| Configured Analysis Entries |
`logicalName` | `output_entries_virtual` |
x-tag-expanded: 'false'
- name: Connections
description: >
**Connections** represent external data source (such as Databricks)
configured in MindBridge. Connections allow you to connect to
external databases, test connectivity, discover available tables, and
retrieve data for use in MindBridge.
x-tag-expanded: 'false'
- name: Populations
description: >
**Populations** allow users to group entries within an analysis to support
more efficient sampling. Unique populations can be defined within
libraries, engagements, and analyses, and can be used to surface or
exclude groups of entries from the analysis results.
Some fields (below) within population entities may only be defined for
populations depending on their parent entity.
Library populations:
- `libraryId`
Engagement populations:
- `engagementId`
- `derivedFromLibrary`
- `disabledForAnalysisIds`
- `promotedFromAnalysisId`
Analysis populations:
- `analysisId`
- `derivedFromEngagement`
Each population inherits permissions from its parent entity type. In order
to access library, engagement, and analysis populations, you will
need to be able to access libraries, engagements, and analyses
respectively. If the API token does not provide sufficient access, those
populations will be excluded from `GET` and /`query` results.
### Population conditions
Populations use the same condition format as saved filters. Please refer
to the saved filters documentation for a description on how the
condition formats work.
Population conditions have additional restrictions in addition to those
applied to saved filters:
- The following fields cannot be used as part of a population condition:
`populations`, `account_tags_decreasing`,
`account_tags_increasing`, `status` and `risk_range`.
- Populations can only be applied to general ledger analysis types.
Unlike filters, populations are validated on creation and when updated. A
create or update to a population condition that doesn't align with
the analysis' data table definition will fail.
Additionally, unlike filters, populations can only be applied to general
ledger entries, not transactions.
Similar to filters, populations include the fields `legacyFilterFormat`,
`displayCurrencyCode` and `displayLocale`, which function in the
same way as they do for saved filters.
x-tag-expanded: 'false'
- name: Webhook event logs
description: >
The webhook event logs provide a way to track events as they are sent by
the system, and allow the user
to help track messages, or diagnose issues with webhooks.
See the webhooks documentation for more information on receiving webhooks,
or the webhook section for information
about the webhooks themselves.
x-tag-expanded: 'false'
- name: Users
description: >
**Users** generally represent you and your team and can be assigned to
various roles and tasks within the platform. Users may also represent
MindBridge Customer Support staff who are active in customer assistance
requests, as well as portal users when connecting integrations and
API Token Users.
### User roles
User roles determine which actions a user can perform within MindBridge.
| Role ID | User Role |
Description
|
|-------------------------------------------------|----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| ROLE_ADMIN | App Admin |
App Admins have full access to the MindBridge tenant. They can invite and
manage users, and view/edit all organizations and
engagements.
|
| ROLE_USER_ADMIN | User Admin |
User Admins can invite and manage tenant users, and create new
organizations.
|
| ROLE_ORGANIZATION_ADMIN | Organization Creator |
Organization Creators have the same privileges as users, but can also
create new
organizations.
|
| ROLE_USER | User |
Users can be invited to existing organizations and engagements, but they
cannot create new
organizations.
|
| ROLE_CLIENT | Client |
Clients must be [invited to
connect](https://support.mindbridge.ai/hc/en-us/articles/1500001350402) to
MindBridge. Once the client account has been activated via email, access
is limited to the page that allows them to set up a data source. |
| ROLE_MINDBRIDGE_SUPPORT | MindBridge Support |
MindBridge Support accounts have limited access to engagements, enabling
them to assist with specific support
requests.
|
| * ROLE_ADMIN and `serviceAccount` equals `true` | API Token User |
API Token Users are non-human user accounts linked to unique API tokens.
Any action that an API takes will be attributed to this user
account.
|
### Enabling and disabling users
The `enabled` property can be used to enable and disable user accounts
within a single tenant. If a user’s account is _disabled_, they will
no longer have access to the tenant until they are _enabled_.
**Note:** A user who is disabled in one tenant will still be able to
access other tenants where they are enabled.
### Account activation emails
When a new user is created, they will be sent an **account activation
email**. This email contains a link they must use to activate their
account. Until the account is activated, the user will not be able to sign
in.
Activation links expire after 7 days, but additional account activation
emails can be sent using the `Resend Activation Link` endpoint.
When a user who is `disabled` becomes `enabled` again, they will be sent
an activation email. These users must use the account activation
link before they can sign in.
### API token permissions
The following table details the actions that users of the API may be
permitted to take:
| Role | Read | Query | Create | Update user enabled
status | Update user role | Can update role to | Delete | Can be sent
account activation emails |
|----------------------|:----:|:-----:|:------:|:--------------------------:|:----------------:|:------------------:|:------:|:-------------------------------------:|
| App Admin | ✅ | ✅ | ✅ |
❌ | ❌ | ✅ | ❌
| ✅ |
| User Admin | ✅ | ✅ | ✅ |
✅ | ✅ | ✅ | ✅
| ✅ |
| Organization Manager | ✅ | ✅ | ✅ |
✅ | ✅ | ✅ | ✅
| ✅ |
| User | ✅ | ✅ | ✅ |
✅ | ✅ | ✅ | ✅
| ✅ |
| Client | ✅ | ✅ | ❌ |
✅ | ❌ | ❌ | ✅
| ✅ |
| MindBridge Support | ✅ | ✅ | ❌ |
❌ | ❌ | ❌ | ❌
| ❌ |
| API Token | ✅ | ✅ | ❌ |
❌ | ❌ | ❌ | ❌
| ❌ |
App Admins cannot be deleted, nor have their roles updated. This
restriction prevents an API token from accidentally locking out a
legitimate administrator, resulting in the loss of administration to the
entire tenant.
MindBridge Support and API Token Users cannot be created, updated, deleted
or sent account activation emails to. These accounts are
automatically managed by support access requests and API tokens
accordingly.
Client users serve a special purpose and cannot be created, nor have their
roles updated. These users can only provide access to an
integration service.
x-tag-expanded: 'false'
- name: Account Groups
description: >
An **account group** is an individual entry within an account grouping.
The lowest-level category for each account group
must be mapped
to [MindBridge Account Classification (MAC)
codes](https://support.mindbridge.ai/hc/en-us/articles/22819163288343-MindBridge-Account-Classification-code-system-MAC-v-2),
and optionally, assigned account tags for further classification.
Account groups can be updated as needed until the account grouping is
published. Once published, existing account groups
cannot be updated, but new account groups can be added to the account
grouping using the `append` endpoint.
x-tag-expanded: 'false'
- name: JSON Tables
description: >
A JSON Table is a collection of tabular data structured into one or more
pages of JSON arrays, imported into the MindBridge platform. Each
array consists of objects, where for each object, the keys represent
column headers and their associated values represent the data for
that column. Data must be uploaded sequentially, one page at a time, as
concurrent page uploads are not supported.
Once all data has been appended to the JSON Table, a file manager file can
be created using the file manager's
`Import From JSON Table` endpoint, which merges all the parts into a
concatenated CSV file.
The headers in the resulting file are based on those specified in the JSON
Table, and the order of the headers will correspond to the
sequence in which each unique header appears in the source data.
For example, given the following two pages of JSON Table data:
```json
[
{
"Account": "First Account",
"Amount": "10.11$",
"Date": "2020-01-01"
},
{
"Account": "Second Account",
"Amount": "89.99$",
"Date": "2020-01-02"
}
]
```
```json
[
{
"Account": "Third Account",
"Amount": "33.31$",
"Date": "2020-01-03"
},
{
"Account": "Fourth Account",
"Amount": "10.11$",
"Memo": "My Memo"
}
]
```
The resulting CSV file would be the following:
```
"Account","Amount","Date","Memo"
"First Account","10.11$","2020-01-01",""
"Second Account","89.99$","2020-01-02",""
"Third Account","33.31$","2020-01-03",""
"Fourth Account","10.11$","","My Memo"
```
### JSON Table entities cleanup
JSON Table entities that are more than **7 days** old will be deleted. To
avoid data loss, ensure that all JSON Table entries are imported
as file manager files once all the data has been imported.
x-tag-expanded: 'false'
- name: Transaction ID Previews
description: >
**Transaction ID previews** contain the data behind our transaction ID
generation and analysis system. In this object, analytic data about a
proposed transaction ID is provided to guide the selection of the most
appropriate, granular transaction ID, with as few single-entry
transactions as possible. An appropriate transaction ID enables
MindBridge’s analytics engine to detect anomalies that are more relevant
and insightful.
x-tag-expanded: 'false'
- name: Connection Data Sources
description: >
**Connection Data Sources** represent a table from an external connection
that has been registered for use in MindBridge. A connection data
source stores a chosen table ID and a schema defining which columns to
include — the schema does not need to include all columns from the
table, allowing you to exclude columns that are not needed. Once created,
data can be retrieved from the source for use in MindBridge.
x-tag-expanded: 'false'
- name: Saved Filters
description: >
**Saved Filters** are used to filter data tables in order to easily and
repeatedly extract insights on large sets of data. The saved filters
endpoint allows for easy creation and management of saved filters, and
validation of the applicability of filters across different data
tables and even across engagements and organizations.
Saved filters contain **conditions**, which are definitions on how the
filter applies constraints on the underlying data table. These
conditions contain a field, type and various parameters depending on the
condition type.
The field can either specify a column in the data table (with some
constraints), or a special case field name, which provides the ability to
filter the data table on features of the dataset that are not represented
by a specific column.
The condition type determines how the data will be filtered. Which types
can be applied depends on the data table's column type and other
properties. For special case filters the type parameters depend on the
underlying data table and analysis features. See the *Condition
Types* section for more details.
Saved filters can be used to filter general ledger, accounts payable, and
accounts receivable analyses. They cannot be used as part of
custom analysis types.
### Validation
Saved filters are different from other entities in the MindBridge API in
that the filter conditions are not immediately validated upon
creation. This is because they may or may not be applicable to different
target data tables based on the analysis features and the column
present in the data table, and their types. To validate whether a given
filter is compatible on a target data table a `/validate` endpoint
is provided, which will return a list of errors and warnings explaining
incompatibilities between the provided filter and the target data
table.
### Display fields
Saved Filter conditions include various fields that are used in generating
a description of the filter for each condition. This description
is visible in the web application and presents the filter in plain
English.
In the web application, filters can only be created in either a library or
analysis context, and have immediate context with which to base
the display fields on. The API doesn't require this context, and can
therefore create filters in contexts the web application can't, such as
on an organization or engagement without any analyses. In order to
generate a sensible filter description for use in the web application,
users of the API can optionally provide these values, and verify if they
align with a target data table using the `/validate` endpoint.
### Filter types
Filters can be of one of four types:
`LIBRARY`, `ORGANIZATION`, `ENGAGEMENT` and `PRIVATE`
Library, organization, and engagement types determine which parent entity
type the filter is stored under, and in some cases restrict which
fields can be used on those filters.
Private filters function like organization filters, but they are only
accessible by the user that created them. This also applies to the API
users, who can only see private filters created by that same token user.
The API cannot be used to access private filter created by other
users, including other token users.
### Filter data type
Filter data type is used to determine what kind of data the filter intends
to target, and can be set to the values: `TRANSACTION_FILE`,
`ENTRIES_FILE` or `LIBRARY_ADMIN_TABLE`.
The `TRANSACTION_FILE` value corresponds to the transactions data table in
a general ledger analysis.
The `ENTRIES_FILE` corresponds to a general ledger, accounts payable and
accounts receivable entries tables.
### Disallowed fields
The following fields cannot be used as conditions:
- `account`, if the analysis is a general ledger analysis
- `accounts` or `mac_hierarchy`, if the data table column type is
`ARRAY_STRINGS`
- `txid`, `rowid` or `matched_entry_id`, if the data table column type is
`INT64`
- `total_amt`, if the data table column type is `MONEY_100`
- `invoice_paid_zero_date`, if the data table column type is `DATE_TIME`
- Any data table column whose field name starts with "`cp_score_`"
- Any data table column whose field name starts with "`risk`", and has
data table column type `PERCENTAGE_FIXED_POINT`
- Any column that does not have a data table column type of
`KEYWORD_SEARCH` or `LEGACY_ACCOUNT_TAG_EFFECTS`, and without one of
`equalitySearch`, `rangeSearch` and `containsSearch` being `true`
### Condition types
Condition's types are determined by their `type` field. Some condition
types also contain subtypes, which further determine what fields are
required to configure them.
Broadly there are 2 types of conditions: Group type conditions, and value
conditions.
Group conditions don't require a field or other properties, and instead
contain a sub-list of conditions that are applied against the data
table entries.
Value conditions filter a specific field and cover all other condition
types other than `GROUP`. In addition to `field` they have the
following properties:
- `fieldLabel` - An optional display name for the field which is used in
the full condition description.
- `negated` - When `true` the condition will instead exclude any entry
that matches the condition from the result.
- `fullConditionDescription` - A description of the filter in plain
English, using the provided display values such as `fieldLabel` and
others.
#### `GROUP` type conditions
Group conditions, also known as rules, don't require a field, and contain
both an operator and a list of conditions. The operation can be
either `AND` or `OR`, and the condition will match records that meet all
or any of the conditions, depending on the operator. Group
conditions can be nested, and the value of the `condition` field on a
saved filter must be a group condition, though it can be either type.
```json
{
"type": "GROUP",
"operator": "AND",
"conditions": [
...
]
}
```
#### `STRING` type conditions
String type conditions compare a field against a specific string value.
This condition can only be applied to the following special case
fields:
| **Field** | **Name** | **Allowed
Values**
| **Notes** |
|------------------|-----------------|---------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------|
| `accountScoping` | Account Scoping | SIGNIFICANT, INSIGNIFICANT,
UNSCOPED
| Only allowed on general ledger analyses. |
| `riskGroup` | Risk Group | Not `GENERAL` or `MindBridge
Score`
ASSETS, LIABILITIES_EQUITY, PROFIT_LOSS, or any custom
account group by `category` name. | Only allowed on general ledger
analyses. |
#### `STRING_ARRAY` type conditions
String array conditions compare the field against a set of string values.
It can be applied to any data table column with the following
properties:
- Data table column type is `STRING` and `caseInsensitivePrefixSearch` is
`true`.
- Data table column type is `KEYWORD_SEARCH`.
#### `CONTROL_POINT` type conditions
Control point conditions match a set of selected control points within
their respective high, medium and low risk scores.
The control point type can only be used with the field `cp_failed` and
when the data table column type is `BOOLEAN_FLAGS`.
The `riskLevel` property can be set to `HIGH_RISK`, `MEDIUM_RISK` or
`LOW_RISK`.
The `controlPoints` contains a list of control point selection models,
with the following properties:
- `id` - The unique ID of the control point prefixed with `custom_`, in
the case of custom control points, or the symbolic name, in the case
of MindBridge control points.
- `name` - The display name of the control point. Optional.
- `symbolicName` - The symbolic name of the control point. In the case of
custom control points it must be the symbolic name of the
underlying MindBridge control point.
- `isRulesBased` - Must be `true` if the target control point is rules
based. Rules based control points can only have high and low risk
values, and therefore cannot be selected with a `riskLevel` of `MEDIUM_RISK`.
Here is an example of both a MindBridge and a custom control point:
```json
{
"type": "CONTROL_POINT",
"field": "cp_failed",
"fieldLabel": "Control point",
"negated": false,
"riskLevel": "HIGH_RISK",
"controlPoints": [
{
"id": "custom_682fab332f732c4d0b8d1ced",
"name": "Expert Rules - Example Custom Control Point",
"symbolicName": "journal_entry_flat_expert_flow_v2",
"rulesBased": false
},
{
"id": "journal_entry_two_digit_benford_v2",
"name": "2 Digit Benford",
"symbolicName": "journal_entry_two_digit_benford_v2",
"rulesBased": false
}
]
}
```
#### `ACCOUNT_NODE_ARRAY` type conditions
Account node array type conditions match an entry if it's within an
account group or specific account code within varying contexts.
This condition type can only be used for general ledger analyses.
The following fields use the account node array type:
| **Field** | **Name** |
**Notes**
|
|---------------------------|--------------------|------------------------------------------------------------------------------------------------------------------------------------------------|
| `account_hierarchy_codes` | Account | Matches if the entry is
associated with an account within the selection of
accounts. |
| `increasingCredits` | Increasing Credits | Matches if the entry is
associated with an account within the selection of accounts and the credit
value within those accounts are increasing. |
| `increasingDebits` | Increasing Debits | Matches if the entry is
associated with an account within the selection of accounts and the debit
value within those accounts are increasing. |
Both `increasingCredits` and `increasingDebits` are special case fields
and can be used even if they are not present as data table columns.
When using an `ACCOUNT_NODE_ARRAY` condition a list of account selections
must be provided with the following properties:
- `name` - The display name of the account. Optional.
- `code` - The account group or account ID of the account.
- `useAccountId` - If `true` the condition should match the account id
from the account mapping instead of the account group ID for this
selection.
Here is an example of a condition that matches both an account group and a
mapped account:
```json
{
"type": "ACCOUNT_NODE_ARRAY",
"field": "increasingCredits",
"fieldLabel": "Increasing credits",
"negated": false,
"accountSelections": [
{
"name": "Assets",
"code": "1000",
"useAccountId": false
},
{
"name": "Accounts Payable",
"code": "21011",
"useAccountId": true
}
]
}
```
#### `TYPEAHEAD_ENTRY` type condition
The typeahead entry type condition can be used to match one or more string
values within a known set of allowed values. They are used both
to filter columns that have been mapped to certain MindBridge field and
additional columns marked as filterable. There are also additional
special case field that can be used for various purposes.
| **Field** | **Name** |
**Notes**
|
|-------------------------------|-------------------------|-----------------------------------------------------------------------------------------|
| `status` | Status | Matches
entries which contain corresponding tasks with the selected
statuses. |
| `memo` | Suspicious keyword | Allowed values
are from the Suspicious keyword control point. |
| `entriesFundRestriction` | Fund restriction | Allowed values
are `restricted`, `unrestricted` and `none` |
| `transactionsFundRestriction` | Fund restriction | Allowed values
are `restricted`, `unrestricted`, `both` and `none` |
| `account_tags_increasing` | Increasing account tags | Matches
entries whose accounts using the provided account tags have increased in
value. |
| `account_tags_decreasing` | Decreasing account tags | Matches
entries whose accounts using the provided account tags have decreased in
value. |
In addition to the above field, any data table column with the type
`STRING` or `ARRAY_STRINGS` and an ID set for `typeaheadDataTableId` can
be used in a typeahead entry condition. The allowed values for typeahead
based fields are any of the values present in the column. Typeahead
column values are not currently validated, so no warnings will be produced
if a value that is not present in the column is used as an entry.
A value selection for a typeahead entry has three properties: `lookupId`,
which is the value being selected, `displayName`, which is the
display name of the underlying value, and `hideLookupId`, which hides the
lookup ID when displaying the full display name.
Here is an example of a typeahead entry condition:
```json
{
"type": "TYPEAHEAD_ENTRY",
"field": "entriesFundRestriction",
"fieldLabel": "Fund restriction",
"negated": false,
"values": [
{
"lookupId": "none",
"displayName": "No fund information",
"hideLookupId": true
},
{
"lookupId": "restricted",
"displayName": "Restricted funds",
"hideLookupId": true
}
]
}
```
#### `POPULATIONS` type condition
The populations type condition matches any entries that are within the
provided populations.
Population type conditions can only be used in general ledger analyses,
and can only be used in saved filters at the analysis level.
Populations type conditions must use the special case field `population`.
Population type conditions can only be applied to general ledger
analyses.
To include a population in the condition it simply needs to be added to
the `populationIds` field. In addition to IDs, population category
names can be present in the population IDs list for display purposes.
Here is an example of a populations filter:
```json
{
"type": "POPULATIONS",
"field": "population",
"fieldLabel": "Population",
"negated": false,
"populationIds": [
"Custom Category",
"67d06587edfa507f5e80c7c2"
]
}
```
#### `RISK_SCORE` type condition
A risk score condition matches entries whose risk score falls within the
constraints configured in the condition.
The specific risk score being tested is selected by setting the
`riskScoreId` field to the field of the target risk score, as found in the
data table column metadata.
Risk scores are used on the special case fields `riskScoresHml` or
`riskScoresPercentage`, depending on the library configuration for the
analysis. Additionally, the `riskScoreType` must be set to `HML` or
`PERCENT` accordingly.
For HML type risk score conditions a set of the values `HIGH`, `MEDIUM`,
`LOW` or `UNSCORED`, which match entries that fall within the
configured risk range for the selected risk score.
Here is an example of a HML risk score filter on a custom risk score:
```json
{
"type": "RISK_SCORE",
"field": "riskScoresHml",
"fieldLabel": "Risk score",
"negated": false,
"riskScoreType": "HML",
"riskScoreId": "risk_67d2f16d9ffead02b4f54aad",
"riskScoreLabel": "My custom risk score",
"values": [
"MEDIUM",
"UNSCORED"
]
}
```
For percentage risk score conditions a `riskScorePercentType` of
`MORE_THAN`, `LESS_THAN`, `BETWEEN`, `CUSTOM_RANGE` or `UNSCORED` is set.
These determine how the rule will be applied, and which parameters can be
set.
For `UNSCORED` only entries that haven't been scored are matched.
For `MORE_THAN` and `LESS_THAN`, a `value` parameter must be set with a
number from 0 to 10,000, representing a percentage between 0% to
100%, and matching entries with scores above or below the specified value.
For `CUSTOM_RANGE` a pair of percentage values `rangeStart` and `rangeEnd`
are set. Any entries whose score falls between the values will be
matched.
`BETWEEN` is functionally equivalent to custom range, with the restriction
that the `rangeStart` and `rangeEnd` must equal the start and end
values of one of the risk score's risk range entries (high, medium or low
risk). In the web application this is represented as the user
selecting an existing risk range, rather than manually entering a pair of
percentages as custom range requires.
Here is an example of a percentage risk score filter:
```json
{
"type": "RISK_SCORE",
"field": "riskScoresPercentage",
"fieldLabel": "Risk score",
"negated": false,
"riskScoreType": "PERCENT",
"riskScoreId": "risk",
"riskScoreLabel": "MindBridge score",
"riskScorePercentType": "MORE_THAN",
"value": 0
}
```
#### `MONETARY_FLOW` type condition
The `MONETARY_FLOW` type condition matches entries that are part of a
monetary flow corresponding to the filter's configuration.
This condition type can only be used in general ledger analyses.
Only the special case field `monetarySpecificFlow` can be used with this
condition type.
The property `monetaryFlowType` must be set to one of the following
values, which determine what kind of flow to include entries from:
`SIMPLE_FLOW`, `COMPLEX_FLOW` or `SPECIFIC_FLOW`.
For simple and complex flow values, entries that are part of simple
account to account flows, or flows that are too complex to assign to an
account are included.
For specific flows a pair of credit and debit account selections,
`creditAccount` and `debitAccount` accordingly are set. These use the same
parameters as the account node array condition. In addition, the code may
be set to `complex` to match flows whose credit or debit account
is
determined to be too complex to match.
Additionally for specific flows a value for `specificMonetaryFlowType`
must be set, which further filters the entries based on the specific
value of the flow. The following values can be used:
- `SPECIFIC_VALUE` - by setting the `value` field to a currency amount
only entries whose flow amount matches the value exactly will be
matched.
- `MORE_THAN` - by setting the `value` field to a currency amount only
entries where the flow value exceeds that amount will be matched.
- `BETWEEN` - a pair of `rangeStart` and `rangeEnd` values only entries
whose value is between the specified currency amounts.
Currency amounts are expressed as integers, and do not include decimal
places. They follow the same formatting rules as `MONEY_100` fields.
See the *Data Formats* section for more information.
Here is an example of a monetary flow condition:
```json
{
"type": "MONETARY_FLOW",
"field": "monetarySpecificFlow",
"fieldLabel": "Monetary flow",
"negated": false,
"monetaryFlowType": "SPECIFIC_FLOW",
"creditAccount": {
"name": "Flows too complex to determine a match",
"code": "complex",
"useAccountId": false
},
"debitAccount": {
"name": "Operational assets",
"code": "1100",
"useAccountId": false
},
"specificMonetaryFlowType": "BETWEEN",
"rangeStart": 0,
"rangeEnd": 1037979412
}
```
#### `MONEY` type condition
The money type condition matches entries whose value for the provided
field is within the configured bounds of the condition.
The money type condition can be applied to any field with a data table
column type of `MONEY_100`.
The following `monetaryValueType` values can be used to configure how the
entries are matched:
- `MORE_THAN` - Matches entries whose value is more than the configured
`value` field.
- `LESS_THAN` - Matches entries whose value is less than the configured
`value` field.
- `SPECIFIC_VALUE` - Matches entries whose value is equal to the
configured `value` field.
- `BETWEEN` - Matches entries whose value is between the provided
`rangeStart` and `rangeEnd` values.
The values for `value`, `rangeStart` and `rangeEnd` follow the same
formatting rules as the `MONEY_100` data type.
Here is an example of a money type condition:
```json
{
"type": "MONEY",
"field": "bs_delta",
"fieldLabel": "Balance sheet impact",
"negated": false,
"monetaryValueType": "MORE_THAN",
"value": 0
}
```
#### `MATERIALITY` type condition
The materiality type condition matches entries that are above, below or
above a percentage of the threshold.
The materiality type condition can be applied to general ledger analyses
with a materiality judgment value set, and can only be applied to
the special case `materiality` field.
The following `materialityOption` values can be used to configure how the
entries are matched:
- `ABOVE` - Matches entries whose value is above the materiality
threshold.
- `BELOW` - Matches entries whose value is below the materiality
threshold.
- `PERCENTAGE` - Matches entries whose value is above a percent of the
materiality threshold. The percent is a decimal number set in the
`value` field, and can be greater than 100%.
Here is an example of a materiality type condition, and represents a
percentage value of 110.25%:
```json
{
"type": "MATERIALITY",
"field": "materiality",
"fieldLabel": "Materiality",
"negated": false,
"materialityOption": "PERCENTAGE",
"value": 110.25
}
```
#### `NUMERICAL` type condition
The numerical type condition matches entries whose value for the provided
field is within the configured bounds of the condition.
This condition can be applied to any field with a data table column types
of `INT32`, `INT64`, `FLOAT32` and `FLOAT64`.
The following `numericalValueType` values can be used to configure how the
entries are matched:
- `MORE_THAN` - Matches entries whose value is more than the configured
`value` field.
- `LESS_THAN` - Matches entries whose value is less than the configured
`value` field.
- `SPECIFIC_VALUE` - Matches entries whose value is equal to the
configured `value` field.
- `BETWEEN` - Matches entries whose value is between the provided
`rangeStart` and `rangeEnd` values.
Here is an example of a numerical type condition:
```json
{
"type": "NUMERICAL",
"field": "entries_count",
"fieldLabel": "Entries count",
"negated": false,
"numericalValueType": "MORE_THAN",
"value": 0
}
```
#### `DATE` type condition
The date type condition matches entries whose value for the provided field
is within the configured bounds of the condition.
The numerical type condition can be applied to any field with a data table
column types of `DATE` and `DATE_TIME`.
The following `numericalValueType` values can be used to configure how the
entries are matched:
- `AFTER` - Matches entries whose value is more than the configured
`value` field.
- `BEFORE` - Matches entries whose value is less than the configured
`value` field.
- `SPECIFIC_VALUE` - Matches entries whose value is equal to the
configured `value` field.
- `BETWEEN` - Matches entries whose value is between the provided
`rangeStart` and `rangeEnd` values.
The values for `value`, `rangeStart` and `rangeEnd` should be expressed as
ISO date strings, without a timestamp or timezone.
Here is an example of a date type condition:
```json
{
"type": "DATE",
"field": "effective_date",
"fieldLabel": "Effective date",
"negated": false,
"dateType": "SPECIFIC_VALUE",
"value": "2010-01-01"
}
```
### Legacy filters
Saved filters with the `legacyFilterFormat` field set to `true` are using
a legacy format which is not supported by the API, and will have
their `condition` property set to `null`.
x-tag-expanded: 'false'
- name: Account Groupings
description: >
An **account grouping** is a custom financial hierarchy that MindBridge
uses to interpret accounts and the relationships
between them, and defines how accounts are aggregated and presented in
analysis results across the MindBridge platform
and reports. When you create an account grouping, you must map account
groups
to [MindBridge Account Classification (MAC)
codes](https://support.mindbridge.ai/hc/en-us/articles/22819163288343-MindBridge-Account-Classification-code-system-MAC-v-2).
This mapping enables MindBridge to effectively analyze datasets across any
engagements and analyses that use a given
account grouping.
## Creating a new account grouping
To create a new account grouping, import a
completed
[MACv2_AccountGroupingTemplate](https://support.mindbridge.ai/hc/en-us/articles/22819163288343)*
Excel file or
a _CCH group trial balance_ file as a chunked file. Import the new file
using the `/import-from-chunked-file` endpoint.
This action will create a new account grouping entry and a complete set of
account groups and MAC mappings, as defined
in the imported file.
***Note:** The exportable template is located at the bottom of the linked
article. Once you have the template, follow
the steps linked here to [create a new account
grouping](https://support.mindbridge.ai/hc/en-us/articles/360056330754).
## Appending to an existing account grouping
To append to an existing account grouping, export the most current version
of your MindBridge account grouping, then add
new account groups to the bottom of the account grouping, starting from
the first empty row. Next, save the file and
import it as a chunked file, then import the new file using the
`/append-from-chunked-file` endpoint. This action will
add the new account groups and mappings to the end of the existing account
grouping.
**Note:** _CCH group trial balance_ files may not be used when appending
to an existing account grouping.
## Publishing an account grouping
Account groupings must be published before they can be added to a library.
In order to be published, errors must be
resolved for all account groups within the account grouping, and the
lowest-level account categories for each account
group must be mapped to a MAC code. To publish an account grouping, set
the `publishStatus` field to `PUBLISHED`.
Upon publishing, all the account groups within the account grouping are
finalized and can no longer be updated, however
the account grouping can still be appended to. Appending will change the
account grouping’s `publishStatus`
to `UNPUBLISHED_CHANGES`.
From the `UNPUBLISHED_CHANGES`, the account grouping can be re-published
after fixing all account group errors, then
updating the `publishStatus` field to `PUBLISHED`.
x-tag-expanded: 'false'
- name: File Results
description: >
**File results** are the results of asynchronous processes that produce
files. They can be exported once the async result reports that the task
is complete.
File results are restricted to the API token that started the export
process. File results created by another user or API token cannot be
accessed.
x-tag-expanded: 'false'
- name: Analysis Types
description: >
**Analysis types** describe the features of each analysis, such as
specific account mappings or whether the analysis
supports fund accounts, as well as the source configurations used for a
given analysis type.
[Learn more about the types of analyses available within
MindBridge](https://support.mindbridge.ai/hc/en-us/articles/360058198913-Analysis-types-available-in-MindBridge)
x-tag-expanded: 'false'
- name: Admin reports
description: >
**Admin reports** are reports that can be run to summarize user and system
activity.
Currently, the following reports can be run:
- **Activity report** – This report lists activity between the specified
dates and filters
- **Analysis overview report** – This report lists analyses and the
associated risk score results.
- **Row usage report** – This report lists analyses completed within your
specified date range along with the number of rows in each primary current
period data file.
x-tag-expanded: 'false'
- name: Analysis Results
description: >
An **analysis result** is a logical grouping of financial data that has
been run through a series of rules-based,
statistical, and machine-learning tests.
Each time an analysis is run (or re-run), it will generate a distinct
analysis result. Running an analysis multiple
times will result in multiple sets of analysis results.
### Task and data table migration for the periodic time frame
When an analysis using the _periodic_ time frame is re-run, any existing
tasks or data tables created on the latest
analysis result will be migrated to the new analysis result. Upon
completion, the `id` field will be updated to a new
value, and the `analysisResultId` field will be updated with the ID of the
new analysis result.
**Note**: This does not apply to _full_ or _interim_ time frames, wherein
rolling forward, duplicating, or converting interim
analyses causes a new analysis being created, with the original analysis
results' tasks and data tables remaining in
place.
x-tag-expanded: 'false'
- name: File Info
description: >
_File Info_ is an entity used to describe metadata for a file within the
MindBridge application. Every file has an associated File Info
record. If the system detects tabular data in the file, the File Info is
automatically upgraded to a Tabular File Info, which includes
additional metadata describing the table and columns.
The type of file info is determined by the `type` field. If the value is
`FILE_INFO`, the record is a file info. If the value is
`TABULAR_FILE_INFO`, the record is a tabular file info.
x-tag-expanded: 'false'
- name: Engagement Account Groups
description: >
An **engagement account group** is an individual entry within an
engagement account grouping.
x-tag-expanded: 'false'
- name: Chunked Files
description: >
Importing **chunked files** allows you to bypass the 8 GiB import limit by
splitting a large file into smaller files (“chunks”). Each chunk
can be individually retried in case of a network failure, but the entire
import process must be completed within 7 days.
### How it works:
- Create a chunked file.
- Add chunked file parts.
- Create a file manager file from a chunked file.
x-tag-expanded: 'false'
- name: Analysis Sources
description: >
An **analysis source** represents a table of data (often from a file) that
is required to run an analysis. These objects
contain ingestion metadata, including data formats, density and frequency
analysis, and much more. The analysis sources
are the core object types used during the data import process and provide
the data necessary to complete the analysis.
### Analysis source type
An **analysis source type** determines which features are available during
the analysis source import process, and must
be selected when creating an analysis source.
Refer to the `Analysis Type` endpoint to determine which analysis source
types can be applied to a given analysis.
Refer to the `Analysis Source Type` endpoint to determine the features and
column mappings for a given analysis source
type.
#### Additional Analysis Data
**Additional data** is available as an analysis source type for all
analysis types. When creating an additional data
analysis source, the `additionalDataColumnField` property must be set to
the additional data field added during the
import of other source types. A list of the analysis' additional data
columns is available from its `importantColumns`
field.
### Async create and update responses
Unlike other entities, the analysis source entity may perform long-running
background jobs as a result of a `Create`
or `Update` call. As a result, calls to `Create` or `Update` an analysis
source will return an **async result** entity.
Users should poll this entity and await its completion before re-loading
the analysis source and making further changes.
### Analysis Source workflow
Unlike other entities, importing an analysis source relies on a multi-step
workflow process. Which steps are included is
determined by which **features** the analysis source type supports. These
features include multiple **workflow states**,
which determine the current location of the analysis source within the
workflow.
There are two workflow state types: **step states** and **transition
states**.
- Step states allow users to configure properties on an analysis source,
or the analysis more broadly. Some step states
are provided for the MindBridge web app interface and may have little to no meaningful interaction with the API.
- Transition states indicate that the analysis source is performing work
asynchronously, and will eventually transition
to another state.
Here is a list of features and their possible workflow states:
| Feature | State name | State type
|
|--------------------------|----------------------------------|------------|
| Feature independent | STARTED | Transition
|
| Format detection | DETECTING_FORMAT | Transition
|
| | FORMAT_DETECTED | Step
|
| | FORMAT_DETECTION_COMPLETED | Transition
|
| Data validation | ANALYZING_COLUMNS | Transition
|
| | COLUMNS_ANALYZED | Step
|
| Column mapping | DATA_VALIDATION_CONFIRMED | Step
|
| | COLUMN_MAPPINGS_CONFIRMED | Transition
|
| Effective date metrics | ANALYZING_EFFECTIVE_DATE_METRICS | Transition
|
| | EFFECTIVE_DATE_METRICS_ANALYZED | Step
|
| | ANALYSIS_PERIOD_SELECTED | Transition
|
| Transaction ID selection | CHECKING_INTEGRITY | Transition
|
| | INTEGRITY_CHECKED | Step
|
| Parse | PARSING | Transition
|
| | PARSED | Step
|
| Review Funds | FUNDS_REVIEWED | Step
|
| Confirm Settings | SETTINGS_CONFIRMED | Transition
|
| Feature independent | COMPLETED | Step
|
| | FAILED | Step
|
### Transitioning between states
To transition between workflow states, set the `targetWorkflowState`
property to the name of the desired workflow state.
Once set, the workflow will attempt to advance to that state, passing
through all states between the current and target
state without stopping.
If the target state is a transition state, the workflow will continue past
it until it reaches the next step state.
When creating a new analysis source, if `targetWorkflowState` is not set,
the workflow will advance to the first valid
step state, then stop.
These rules apply to all transitions, with a few exceptions:
- If an [ungrouped
format](https://support.mindbridge.ai/hc/en-us/articles/10437018464407) is
detected within the
selected source file, the FORMAT_DETECTED state will be ignored. Setting `targetWorkflowState` to FORMAT_DETECTED on a
source file containing ungrouped data will result in the workflow continuing to the next step state.
- If the final workflow state type is a step state, the workflow will
advance to COMPLETED instead of stopping. This is
often the case with the PARSED state, as it is the final feature state for many source types.
- If an error occurs during a workflow process, the workflow will
transition to FAILED. The cause of the failure can
often be found in the async result or in the analysis source’s `errors` property.
### Feature properties
Certain feature properties may only be read or set on or after specific
workflow states. Here is a breakdown of the
relationship between workflow states and analysis source properties:
#### Format detection
If a [grouped
data](https://support.mindbridge.ai/hc/en-us/articles/10437018464407)
format is detected, the workflow
will stop at the FORMAT_DETECTED state. Then, the `detectedFormat`
property will return the name of the detected format.
From there, the `applyDegrouper` can be set. If `applyDegrouper` is true
then when advancing to the next step, the
relevant formatter will be used to convert the file into a readable
format. If not, the file will be used as is.
`applyDegrouper` can be set immediately upon creation of the analysis
source. If this is done and grouped data is
detected within the workflow, instead of stopping on FORMAT_DETECTED it
will implicitly apply the formatter and continue
to the next workflow state.
If the formatter is used in either scenario, the `degrouperApplied`
property will be set to `true`.
The `presetHeaderRowIndex` field can be set to manually specify the header
row’s position in the imported file, bypassing automatic header
detection. The field is zero-based, so the first row in the file is
considered row 0.
#### Data validation
Upon reaching the COLUMNS_ANALYZED state, the `fileInfo` property is
populated with information, including metadata for
the individual columns (which is available as part of the `columnData`
property) and for the file as a whole (available
under the `metadata` property).
Metrics contain a `state` property, which may appear as `PASS`, `WARN`, or
`FAIL`. These serve as status indicators and
may warn of problems with the file’s data.
#### Column mapping
Upon reaching the DATA_VALIDATION_CONFIRMED state, the
`proposedVirtualColumns`, `proposedColumnMappings`,
and `proposedAmbiguousColumnResolutions` properties are applied, and the
`virtualColumns`, `columnMappings`,
and `ambiguousColumnResolutions` properties are updated accordingly. More
information on the proposed fields is
available in the **Full source import automation** section.
If no value is present for `proposedColumnMappings`, then a set of
recommended column mappings will be applied to the
file.
The API handles column mapping by assigning a column from the file to a
MindBridge field with a compatible data type. To
do this, an entry in the `columnMappings` array must contain both the
`position` of the column from the source file and
the target `mindbridgeField` to assign it to.
#### Virtual columns
[Virtual
columns](https://support.mindbridge.ai/hc/en-us/articles/10442701235223)
can be added, modified, and removed by
changing the `virtualColumns` property. Once created, virtual columns have
a `position` property that can be used in
column mapping; the metrics in `fileInfo` will be updated accordingly.
#### Ambiguous column resolution
While MindBridge can detect usable date formats, including different
formats that appear within a single column, in some
cases the format of date and currency fields cannot be determined from the
dataset provided. For example, the date
format `1/2/2022` could either be January 2nd, 2022, or February 1st,
2022, depending on which date format is being
used. When ambiguous columns are detected, an entry in the
`ambiguousColumnResolutions` property will be created with a
list of all the possible formats in its `ambiguousFormats` property. To
resolve this issue, the correct format from the
list of `ambiguousFormats` should be set in the `selectedFormat` property.
#### Additional data
Unmapped columns may be added as additional data columns. To do so, a
special mapping must be created with
the `mindbridgeField` left blank, and a value set for
`additionalColumnName`. Once this source has completed the import
process, a new source with the same name set for
`additionalDataColumnField` and the source type ID corresponding to the
Additional Data Source Type can be created.
#### Effective date metrics
This step confirms that the file’s entries fall within the current
analysis period. Once this state has been reached,
the `analysis-sources/{analysisSourceId}/effective-date-metrics` endpoint
can be used to get a set of metrics regarding
the number of entries within the source’s analysis period. A `period`
value can be used to set the resolution of the
histogram to days, weeks, or months.
#### Transaction ID selection
Transitioning into the [transaction
ID](https://support.mindbridge.ai/hc/en-us/articles/8740577590295)
selection feature
will generate a preview of the selected transaction by
`proposedTransactionIdSelection` and set
the `transactionIdSelection` property to this value. If no value is set, a
set of potential transaction ID selections
will be generated and what is determined to be the best selection,
according to MindBridge's internal tooling, will be
set to the `transactionIdSelection` property.
Details about these **transaction ID previews** can be viewed via the
transaction ID preview endpoints.
When on the INTEGRITY_CHECKED state, changing the `transactionIdSelection`
will either select an existing preview with
the same properties as the currently selected transaction ID, or, if it
doesn’t exist, will generate a new preview for
the selection, and select it.
#### Review funds and confirm settings
These features have no direct interaction with the API and are only
relevant with respect to the web application.
### Full source import automation
When creating a new analysis source it is possible to perform the entire
import process by setting
the `targetWorkflowState` property to `COMPLETED`. As a result of
performing all workflow steps at once, some features
require input to be provided immediately, specifically the column mapping
and transaction ID selection features. To
provide these values, separate `proposed` fields can be set in order to
provide these values instead of relying on the
default column mapping and transaction ID selection behavior.
#### Column mapping
The `proposedVirtualColumns`, `proposedColumnMappings`, and
`proposedAmbiguousColumnResolutions` properties provide the
ability to pre-define their respective properties ahead of running
validation. These proposed versions of the properties
have some key differences from their applied counterparts:
- As validation has not been run and the column positions have not been
determined, the `position` property for virtual
columns isn’t available. As an alternative to the `proposedColumnMappings` property, a `virtualColumnIndex` property
is available and should be used to reference a specific virtual column definition in the `proposedVirtualColumns`
array.
- `proposedAmbiguousColumnResolutions` are not able to determine the
ambiguous formats ahead of validating the file, so
the `ambiguousFormats` property is not available. Additionally, the `position` property can only refer to a physical
column, and not a virtual one.
#### Transaction ID selection
The `proposedTransactionIdSelection` property can be defined immediately
upon creating the analysis source. If it is set
while entering the transaction ID selection feature then a transaction ID
preview will only be generated for that
selection, and `transactionIdSelection` property will be updated
accordingly.
x-tag-expanded: 'false'
- name: Data Connection Tables
description: >
**Connection Tables** represent individual tables discovered from an
external connection. When a Connection's "Get Tables" operation
is performed, the results are stored as Connection Table records. Each
record contains the table's identifier, display name, and
schema (column definitions), and is linked back to both the Connection and
the Connection Tables Result that produced it.
If the "Get Tables" operation is run multiple times on the same
Connection, tables are added, removed, or updated based on their
`tableId`, rather than creating duplicate entries.
x-tag-expanded: 'false'
- name: Analysis Type Configuration
description: >
An analysis type configuration is the configuration of analysis properties
for a given analysis type. Libraries, engagements and analyses
all have analysis type configurations as child entities for each of their
supported analysis types.
When an engagement is created, it will copy the analysis type
configuration from the related library, and again when an analysis is
created
it will copy the analysis type configuration from its related engagement
in turn.
Analysis type configuration allows configuration of settings related to
control points, including grouping and weighting of control points,
as well as the selection of related risk ranges.
x-tag-expanded: 'false'
- name: Connection Tables Results
description: >
**Connection Tables Results** represent the outcome of running a
Connection's "Get Tables" operation. The Connection Tables Result
is stored as a record containing the total number of tables found. The
individual tables discovered are stored as separate
Connection Table records linked back to this Connection Tables Result.
x-tag-expanded: 'false'
- name: Reporting Period Configuration
description: >
**Reporting period configurations** allow users to define specific
reporting periods for analyses.
Creating a reporting period configuration requires both monthly and weekly
reporting periods to refer to the same date ranges.
The monthly reporting period entries should include the period number,
quarter number, the year, start date, and end date for each period.
Similarly, the weekly reporting period entries should contain the week
number, year, start date, and end date.
x-tag-expanded: 'false'
- name: Organizations
description: >
**Organizations** represent each business/client/company/entity that you
analyze with MindBridge. Organizations house all of your client’s
engagements (audit/analysis), account mappings, and any other data
imported into MindBridge for that client.
x-tag-expanded: 'false'
- name: Webhooks
description: >
The webhooks entity provides a way to configure webhook integrations with
other systems. Once created and active webhooks will send event payloads
to the configured URL.
See the webhooks documentation for more information on receiving webhooks.
x-tag-expanded: 'false'
- name: Libraries
description: >
**Libraries** allow teams to standardize their engagements firm-wide by
setting the parameters for each type of analysis
available in MindBridge, including account groupings, ratios, filters, and
risk scores.
New libraries must be created based on an existing library (i.e., a “base
library”). When a base library is selected,
its point-in-time settings and permissions are copied to the new library.
The following system libraries can be selected as base libraries:
* MindBridge for-profit
* MindBridge not-for-profit
* MindBridge not-for-profit with funds
* MindBridge review
x-tag-expanded: 'false'
- name: Analyses
description: >
An **analysis** is a logical grouping of financial data that can be run
through a series of rules-based, statistical, and machine-learning
tests in order to generate analysis results. Once a set of financial data
has been configured and imported, an analysis can be run to
produce an _Analysis Result_ entity, which contains insights into the
provided data.
Analyses require a number of supporting documents in order to run
successfully. After running an analysis, you can view
the results and leverage them to support your audit work.
### Analysis Type
When creating an analysis, you must identify the **type of analysis** you
want to create. To do so, set
the `analysisTypeId` field to the corresponding ID for the specific
analysis type.
The analysis type must be supported by the library used by the engagement.
The supported analysis types are listed in
the library’s `analysisTypeIds` field.
Refer to the Analysis Type endpoint to select an analysis type and review
its settings.
### Analysis Periods
An **analysis period** is the date range for a given period under
analysis. MindBridge supports the analysis of one
current period and up to four prior periods.
To add analysis periods, add analysis period objects to the appropriate
locations in the `analysisPeriods` array.
To modify analysis periods, update the `analysisPeriods` array.
**Note**: Analysis periods will appear in order, with the most recent
appearing in the current period. Periods must not
overlap or have date gaps between them. The `interimAsAtDate` must not be
set for prior periods.
To resize an analysis period, update the `startDate`, `interimAsAtDate`
and/or `endDate` to the desired date. See
“Interim Time Frames” below for details.
To remove an analysis period, remove the target object in the
`analysisPeriods` array. The current period (index `0`)
may not be removed, nor analysis periods that have associated analysis
sources.
If you remove the ID from an analysis period, the analysis period will be
removed and a new period with the same values
will be added, resulting in a new ID being returned.
[Learn more about analysis
periods](https://support.mindbridge.ai/hc/en-us/articles/360056524494-What-is-an-analysis-period)
#### Full Time Frames
The **full time frame** allows your team to import a complete
dataset. [Learn
more](https://support.mindbridge.ai/hc/en-us/articles/19029762802967)
To create an analysis with a full time frame, the `interim` and `periodic`
fields must be `false` in the body of the
Create
Analysis request.
#### Interim Time Frames
The **interim time frame** allows your team to import a portion of a
dataset before
year-end. [Learn
more](https://support.mindbridge.ai/hc/en-us/articles/19030451443223)
To create an analysis with an `interim` time frame, the interim field must
be `true` in the body of the Create Analysis
request. You must also provide an `interimAsAtDate` for the current
period, which defines the last day of the interim
period.
**Note**: The `interim` field cannot be combined with the `periodic`
field, which must be `false` if `interim` is `true`.
**Note**: The interim time frame must be supported by the analysis type in
order to use it.
#### Periodic Time Frames
The **periodic time frame** allows your team to import data on an ongoing
basis, such as monthly or quarterly, over the
course of the analysis period. [Learn
more](https://support.mindbridge.ai/hc/en-us/articles/19034004957591)
To create an analysis with a periodic time frame, the `periodic` field
must be `true` in the body of the Create Analysis
request.
**Note**: The `periodic` field cannot be combined with the `interim`
field, which must be `false` if `periodic`
is `true`.
**Note**: The periodic time frame must be supported by the analysis type
in order to use it. Additionally, the periodic
time frame and the risk monitoring dashboard are disabled by default in
the library's analysis configuration, and must
be enabled by an App Admin before they can be accessed.
### Currency
The **currency code** indicates the type of currency used in the analysis.
A valid currency code must be provided in the `currencyCode` field.
**Note**: MindBridge supports the majority of currencies indicated
in [ISO 4217](https://www.iso.org/iso-4217-currency-codes.html). Currency
code labels used within MindBridge may not
match ISO labels exactly, but support for those currencies still exists.
**Note**: MindBridge does not support currencies that use more than two
decimal places.
### Reporting Periods
MindBridge supports custom reporting periods. If your organization has a
custom reporting period configuration, you can specify it when
creating an analysis by providing the `reportingPeriodConfigurationId`
field with the ID of the desired reporting period configuration.
If no reporting period configuration ID is provided, it inherits the
reporting period set in the engagement. On an update, the existing
value will be used if no value is provided.
x-tag-expanded: 'false'
- name: Engagements
description: >
An **engagement** represents a service or activity performed for one of
your clients. When you create an engagement within an organization,
it will always be associated with that organization. Engagements house the
analyses you run within MindBridge, like the general ledger
analysis.
Typically engagements represent an annual audit, so using MindBridge over
the course of several years will result in multiple engagements
within an organization, each corresponding to a fiscal year.
The reportingPeriodConfigurationId is an optional field. If provided, it
will use the custom reporting period configuration specified by
the ID. If not provided, it will default to the default reporting period
configuration.
x-tag-expanded: 'false'
- name: Risk Ranges
description: >
Risk ranges are customized scoring parameters for grouping risk scores
into low, medium, and high risk range bounds.
Each risk range bound has a low threshold and a high threshold. These
values represent percentage values with two-decimal precision. The
thresholds are
`PERCENTAGE_FIXED_POINT` values, which are percentages with two decimal
places, represented as numbers from 0 to 10,000. For more details on this
data format,
refer to the Data Formats section of the API reference.
You are not required to utilize all risk range bounds, however you must
define at least two ranges. The values must be continuous with no gaps,
and no
overlapping values. If a low risk range has a high threshold of 15%
(represented as `1500`), the low threshold of the next risk range must
start at 15.01% (
represented as `1501`).
Risk ranges are designed to be used in conjunction with analysis type
configurations.
Risk ranges can only be added to libraries, and are copied onto new
engagements that select the library when created. Once copied to the
engagement, the risk
range can no longer be updated.
x-tag-expanded: 'false'
paths:
/v1/async-results/{asyncResultId}:
get:
tags:
- Async Results
summary: Read Async Result
description: >
Read an existing async result, identified by its ID.
### Permissions
This endpoint inherits the permissions from the target entity in scope.
For example, if the async result represents an **analysis source**,
then the requesting token must contain the permission:
`api.analysis-sources.read`.
operationId: readAsyncResult
parameters:
- name: asyncResultId
in: path
required: true
schema:
type: string
responses:
'200':
description: OK
content:
application/json:
schema:
$ref: '#/components/schemas/ApiAsyncResult_Read'
components:
schemas:
ApiAsyncResult_Read:
type: object
properties:
id:
type: string
description: The unique object identifier.
version:
type: integer
format: int64
description: Indicates the data integrity version to ensure data consistency.
creationDate:
type: string
format: date-time
description: The date that the object was originally created.
lastModifiedDate:
type: string
format: date-time
description: The date that the object was last updated or modified.
createdUserInfo:
$ref: '#/components/schemas/ApiUserInfo_Read'
description: Details about the user who created the object.
readOnly: true
lastModifiedUserInfo:
$ref: '#/components/schemas/ApiUserInfo_Read'
description: Details about the user who last modified or updated the object.
readOnly: true
type:
type: string
description: Indicates the type of job being run.
enum:
- ANALYSIS_RUN
- ANALYSIS_SOURCE_INGESTION
- ADMIN_REPORT
- DATA_TABLE_EXPORT
- ANALYSIS_ROLL_FORWARD
- GDPDU_UNPACK_JOB
- ACCOUNT_GROUPING_EXPORT
- ACCOUNT_MAPPING_EXPORT
- DATA_TRANSFORMATION_JOB
- CONNECTION_TEST
- CONNECTION_TABLES
- DATA_TABLE
status:
type: string
description: Indicates the current state of the job.
enum:
- IN_PROGRESS
- COMPLETE
- ERROR
entityId:
type: string
description: Identifies the entity used in the job.
entityType:
type: string
description: Identifies the entity type used in the job.
enum:
- ORGANIZATION
- ENGAGEMENT
- ANALYSIS
- ANALYSIS_RESULT
- ANALYSIS_SOURCE
- FILE_RESULT
- GDPDU_UNPACK_JOB
- ACCOUNT_GROUPING
- ENGAGEMENT_ACCOUNT_GROUPING
- FILE_MANAGER_FILE
- CONNECTION_TEST_RESULT
- CONNECTION_TABLES_RESULT
- DATA_TABLE
error:
type: string
description: The reason why the async job failed.
errorMessage:
type: string
title: Async Result
ApiUserInfo_Read:
type: object
properties:
userId:
type: string
description: Identifies the user.
userName:
type: string
description: The name of the user.
title: User Info
securitySchemes:
mindbridge-api:
type: http
scheme: bearer
bearerFormat: opaque
````