/ /

App Configuration Files

Docs Home

/ /

Reference

App Configuration Files

App Configuration Files

Application Configuration Files (Legacy)

Atlas App Services has reached its end-of-life status and is no longer actively supported by MongoDB. Triggers remain available in the Atlas UI. Refer to the deprecation page for details.

Note

Legacy Page

This page describes the legacy configuration file format used by realm-cli version 1. For an up-to-date description of Atlas App Services configuration files, see App Configuration.

Overview

App Services uses JSON files and source code files to define and configure every component of an application. Each component has a specific configuration file schema and every application uses a standard file structure to organize the configuration files.

When Will I Use Configuration Files?

Every App is composed of a collection of configuration files, so you use application configuration files whenever you create or modify an App. If you use the App Services UI then you rarely deal directly with the configuration files themselves, but other deployment methods, like App Services CLI and GitHub allow you to define and edit the configuration files directly.

Directory Structure

The following figure shows a high-level view of an App's directory structure:

yourRealmApp/
├── config.json
├── secrets.json
├── auth_providers/
│   └── <provider name>.json
├── functions/
│   └── <function name>/
│       ├── config.json
│       └── source.js
├── services/
│   └── <service name>/
│       ├── config.json
│       ├── incoming_webhooks/
│       │   ├── config.json
│       │   └── source.js
│       └── rules/
│           └── <rule name>.json
├── triggers/
│   └── <trigger name>.json
├── hosting/
│   ├── metadata.json
│   └── files/
│       └── <files to host>
└── values/
    └── <value name>.json

Application Configuration

Application-level configuration information is defined in a single document named config.json stored in your application's root directory.

yourRealmApp/
└── config.json

Configuration

config.json

{
  "app_id": "",
  "name": "",
  "security": {
    "allowed_request_origins": ["<Origin URL>"]
  },
  "hosting": {
    "enabled": <boolean>,
    "custom_domain": "<Custom Domain Name>",
    "app_default_domain": "<Default Domain Name>"
  },
  "custom_user_data_config": {
    "enabled": <Boolean>
    "mongo_service_id": "<MongoDB Service ID>",
    "database_name": "<Database Name>",
    "collection_name": "<Collection Name>",
    "user_id_field": "<Field Name>"
  }
  "deployment_model": "<Deployment Model Type>",
  "location": "<Deployment Cloud Region Name>",
  "config_version": <Version Number>
}

Field

Description

app_id

String

The application's App ID.

name

String

The application's name.

Note

App Name Limitations

Application names must be between 1 and 32 characters and may only contain ASCII letters, numbers, underscores, and hyphens.

security

Document

A document that contains configuration options for application-level security features.

"security": {
  "allowed_request_origins": ["<Origin URL>"]
}

Field Name

Description

allowed_request_origins

Array<String>

An array of URLs that incoming requests may originate from. If you define any allowed request origins, then Atlas App Services blocks any incoming request from an origin that is not listed.

Request origins are URLs with the following form:

<scheme>://<host>[:port]

hosting

Document

A document that contains configuration options for all hosted files:

"hosting": {
  "enabled": <boolean>,
  "custom_domain": "<Custom Domain Name>",
  "app_default_domain": "<Default Domain Name>"
}

Field Name	Description
`enabled` Boolean	If `true`, indicates that your application can host static files.
`custom_domain` String	A custom domain name for your application's hosted files.
`app_default_domain` String	The default domain for your application's hosted files. App Services automatically sets this value and you cannot change it.

config_version

Number

The schema version that all configuration files in the application conform to. This value is machine generated and you typically should not manually set or modify it.

custom_user_data_config

Document

A document that contains configuration options for custom user data.

"custom_user_data_config": {
  "enabled": <Boolean>
  "mongo_service_id": "<MongoDB Service ID>",
  "database_name": "<Database Name>",
  "collection_name": "<Collection Name>",
  "user_id_field": "<Field Name>"
}

Field Name	Description
`enabled` Boolean	If `true`, App Services associates each user with a document that contains their data stored in the specified collection.
`mongo_service_id` String	The service ID of the MongoDB Atlas data source that contains the custom user data. You can find this value in the `id` field of the service configuration file.
`database_name` String	The name of the database that contains the custom user data collection.
`collection_name` String	The name of the collection that contains the custom user data.
`user_id_field` String	The name of the field in each custom data document that contains the user ID of the application user the document describes.

deployment_model

String

The application's deployment model. The following values are valid:

Deployment Model	Value
Global Deployment	`"GLOBAL"`
Local Deployment	`"LOCAL"`

location

String

The name of the cloud region that the application is deployed in.

Local applications process all
application requests and database writes in this region.
Global applications process all database writes in this region, but serve other application requests in the nearest deployment region.

Authentication Providers

Authentication providers are defined in your application's /auth_providers directory.

Each provider is defined in its own JSON file named after the provider. For detailed information on configuring and using a specific authentication provider, see that provider's reference page.

yourRealmApp/
└── auth_providers/
    └── <provider name>.json

Configuration

<provider name>.json

{
  "id": "<Provider ID>",
  "name": "<Provider Name>",
  "type": "<Provider Type>",
  "disabled": <Boolean>,
  "config": {
    "<Configuration Option>": <Configuration Value>
  },
  "secret_config": {
    "<Configuration Option>": "<Secret Name>"
  },
  "metadata_fields": [{
    "required": <Boolean>,
    "name": "Field Name"
  }]
}

Field	Description
`id` String	A value that uniquely identifies the authentication provider. Atlas App Services automatically generates a unique ID for a provider when you create it.
`name` String	The name of the authentication provider.
`type` String	The type of the authentication provider. Valid Options: `"anon-user"` `"local-userpass"` `"api-key"` `"oauth2-apple"` `"oauth2-google"` `"oauth2-facebook"` `"custom-token"` `"custom-function"`
`config` Document	A document that contains configuration values that are specific to the authentication provider. The existence of this field and its exact configuration fields depend on the provider type.
`secret_config` Document	A document where each field name is a private configuration field for the provider and the value of each field is the name of a Secret that stores the configuration value.
`metadata_fields` Array<Document>	An array of documents where each document defines a metadata field that describes the user. The existence of this field and the exact format of each metadata field document depends on the provider type.
`disabled` Boolean	If `true`, this authentication provider is not enabled for your application and cannot be used.

Functions

Atlas Functions are defined in a sub-directory of your application's /functions directory. Each function maps to its own subdirectory with the same name as the function.

Each function is configured in config.json and has its source code defined in source.js.

yourRealmApp/
└── functions/
    └── <function name>/
        ├── config.json
        └── source.js

Configuration

config.json

{
  "id": "<Function ID>",
  "name": "<Function Name>",
  "private": <Boolean>,
  "can_evaluate": <Rule Expression>,
  "disable_arg_logs": <Boolean>,
  "run_as_system": <Boolean>,
  "run_as_user_id": "<App Services User ID>",
  "run_as_user_id_script_source": "<Function Source Code>"
}

Field	Description
`id` String	A value that uniquely identifies the function. App Services automatically generates a unique ID for a function when you create it.
`name` String	The name of the function. The name must be unique among all functions in your application.
`private` Boolean	If `true`, this function may only be accessed from HTTPS endpoints, rules, and named functions.
`can_evaluate` Document	A rule expression that evaluates to `true` when the function is allowed to execute in response to a given request.
`disable_arg_logs` Boolean	If `true`, App Services omits the arguments provided to a function from the function execution log entry.
`run_as_system` Boolean	If `true`, this function runs as the system user. This overrides any values defined for `run_as_user_id` and `run_as_user_id_script_source`.
`run_as_user_id` String	The unique ID of a App Services User that the function always executes as. Cannot be used with `run_as_user_id_script_source`.
`run_as_user_id_script_source` String	A stringified function that runs whenever the function is called and returns the unique ID of a App Services User that the function executes as. Cannot be used with `run_as_user_id`.

Source Code

source.js

exports = function() {
  // function code
};

MongoDB Services

Every MongoDB Atlas data source linked to your app is configured as a service in the /services directory. Each data source maps to its own sub-directory with the same name as the service.

The primary service configuration for a MongoDB Atlas data source is config.json, which defines connection parameters and sync rules.

If the data source is not a synced cluster or Federated database instance, then you can define collection-level rules in the /rules sub-directory.

yourRealmApp/
└── services/
    └── <MongoDB Service Name>/
        ├── config.json
        └── rules/
            └── <rule name>.json

Important

MongoDB Service names are not necessarily the same as their linked data source's name in Atlas. You define the service name for a data source when you link it to your application. For linked clusters, the default MongoDB service name is mongodb-atlas. For Federated data sources, the default service name is mongodb-datafederation.

Service Configuration

The configuration file to link an Atlas cluster should have the following form:

config.json

{
  "id": "<Service ID>",
  "name": "<Service Name>",
  "type": "mongodb-atlas",
  "config": {
    "clusterName": "<Atlas Cluster Name>",
    "readPreference": "<Read Preference>",
    "wireProtocolEnabled": <Boolean>,
    "sync": <Sync Configuration>
  }
}

The configuration file for a Federated data source should have the following form:

config.json

{
  "id": "<Service ID>",
  "name": "<Service Name>",
  "type": "datalake",
  "config": {
     "dataLakeName": "<Federated database instance name>"
   }
 }

Exactly one of config.dataLakeName and config.clusterName is required, depending on whether you are linking a cluster or a Federated data source.

Field

Description

id

String

A string that uniquely identifies the service. App Services automatically generates a unique ID for a MongoDB service when you create it.

name

String

The name of the service. The name may be at most 64 characters long and can only contain ASCII letters, numbers, underscores, and hyphens. For clusters, the default name is mongodb-atlas. For Federated data sources, it is mongodb-datafederation.

type

String

For MongoDB Atlas clusters, this value is always "mongodb-atlas". For Federated data sources, this value is "datalake".

config.clusterName

String

Required when linking a cluster. The name of the service's linked cluster in MongoDB Atlas.

config.dataLakeName

String

Required when linking a Federated data sources. The name of the instance that you want to link to your application.

config.readPreference

String

The read preference mode for queries sent through the service. Not available for Federated data sources.

Mode	Description
primary	App Services routes all read operations to the current replica set primary node. This is the default read preference mode.
primaryPreferred	App Services routes all read operations to the current replica set primary node if it's available. If the primary is unavailable, such as during an automatic failover, read requests are routed to a secondary node instead.
secondary	App Services routes all read operations to one of the current replica set secondary nodes.
secondaryPreferred	App Services routes all read operations to one of the replica set's available secondary nodes. If no secondary is available, read requests are routed to the replica set primary instead.
nearest	App Services routes read operations to the replica set member that has the lowest network latency relative to the client.

config.sync

Document

A configuration document that determines if a cluster is synced and, if it is, defines the rules for sync operations on the cluster. Not available for Federated data sources.

For detailed information on sync configuration documents, see Synced Cluster Configuration.

Synced Cluster Configuration

The config.sync field of config.json determines if a cluster is synced and, if it is, defines the rules for sync operations on the cluster.

config.json

{
  ...,
  "config": {
    ...,
    "sync": {
      "state": <Boolean>,
      "development_mode_enabled": <Boolean>,
      "database_name": "<Development Mode Database Name>",
      "partition": {
        "key": "<Partition Key Field Name>",
        "type": "<Partition Key Value Type>",
        "permissions": {
          "read": <JSON Expression>,
          "write": <JSON Expression>
        }
      }
    }
  }
}

Field	Description
`sync.state` Boolean	If `true`, Sync is enabled for the cluster, which means that client applications can sync data in the cluster with Realm Database and that non-sync collection rules do not apply.
`sync.development_mode_enabled` Boolean	If `true`, Development Mode is enabled for the cluster. While enabled, Atlas App Services stores synced objects in a specific database within the cluster, and mirrors object types in that database's collection schemas.
`sync.database_name` String	The name of the database in the synced cluster where App Services should store synced objects. When Development Mode is enabled, App Services stores synced objects in this database. Each object type maps to its own collection in the database with a schema that matches the synced objects.
`sync.partition.key` String	The name of the partition key field that maps data into individual synced realms.
`sync.partition.type` String	The type of the partition key field value.
`sync.partition.permissions` Document	A document that defines the `read` and `write` permissions for the synced cluster. Permissions are defined with rule expressions that App Services evaluates per-user, per-partition. The expressions have access to the `%%user` and `%%partition` expansions.

MongoDB Collection Rules (Non-Sync)

For non-synced clusters, you can define collection-level rules that App Services evaluates dynamically for each request. Each collection's rules are stored in a rules.json file in that collection's configuration subdirectory, which is data_sources/<data-source-name>/<database-name>/<collection-name>/.

Note

Federated data sources do not support rules or schemas. You can only access a Federated data source from a system function.

<database.collection>.json

{
  "id": "<Rule ID>",
  "database": "<Database Name>",
  "collection": "<Collection Name>",
  "roles": [<Role>],
  "schema": <Document Schema>,
  "filters": [<Filter>],
}

Field

Description

id

String

A string that uniquely identifies the trigger. App Services automatically generates a unique ID for a trigger when you create it.

database

String

The name of the database that holds the collection.

collection

String

The name of the collection.

roles

Array<Document>

An array of Role configuration documents, which have the following form:

{
   "name": "<Role Name>",
   "apply_when": { Expression },
   "document_filters": {
     "read": { Expression },
     "write": { Expression }
   },
   "read": { Expression },
   "write": { Expression },
   "insert": { Expression },
   "delete": { Expression },
   "search": <Boolean>,
   "fields": {
      "<Field Name>": {
         "read": { Expression },
         "write": { Expression },
         "fields": { Embedded Fields }
      },
      ...
   },
   "additional_fields": {
     "read": { Expression },
     "write": { Expression }
   }
}

Field

Description

name

string

The name of the role. Role names identify and distinguish between roles in the same collection. Limited to 100 characters or fewer.

apply_when

object

An expression that evaluates to true when this role applies to a user.

When Device Sync (Flexible Mode) is not enabled, App Services assigns a role on a per-document basis. When Device Sync (Flexible Mode) is enabled, App Services assigns roles on a per-collection, per-session basis -- that is, for each synced collection when a client opens a sync connection.

To assign a role, App Services evaluates the apply_when of each potential role until one evaluates to true. Potential roles are any roles specified in the rules.json configuration file for the given collection or, if no rules.json file is found for the given collection, the default role(s). App Services evaluates roles in the order that you specify them in your configuration. If no role matches, then access is denied. For more information, see Role-based Permissions.

If Device Sync (Flexible Mode) is enabled, the assigned roles must be Sync compatible. If the role is not Sync compatible, but its apply_when evaluated to true, others roles are not considered; access is denied.

document_filters
Document
Default: undefined

A document with read and write expressions that determine whether the role's other permissions may be evaluated.

If Device Sync is enabled, both document_filters.read and document_filters.write must be defined to make the role Sync compatible. Sync incompatible roles deny all access to Sync requests.

If Device Sync is not enabled, document_filters, document_filters.read, and document_filters.write are all optional; an undefined document_filters.read or document_filters.write defaults to true, allowing subsequent permissions to be evaluated.

"document_filters": {
  "read": { Expression },
  "write": { Expression }
}

document_filters.read
object?
Default: undefined

An expression that specifies whether read, read permissions in fields, and read permissions in additional_fields may be evaluated. If false (and document_filters.write is undefined or false), read access is denied for the entire document.

To maintain Sync compatibility, the expression must be defined and may only reference queryable fields.

document_filters.write
object?
Default: undefined

An expression that specifies whether write, write permissions in fields, and write permissions in additional_fields may be evaluated. If false, then write access is denied for the entire document.

To maintain Sync compatibility, the expression must be defined and may only reference queryable fields.

read
object?
Default: undefined

An expression that evaluates to true if the role has permission to read all fields in the document.

To maintain Sync compatibility, the expression must be a boolean literal (either true or false).

Document-level read permissions take priority over any field-level permissions. If a role has document-level read permissions, it applies to all fields in the document. Read permissions specified by fields or additional_fields do not override document-level read permissions.

To define a default fallback alongside field-level rules, leave read undefined and use additional_fields.

write
object?
Default: undefined

An expression that evaluates to true if the role has permission to add, modify, or remove all fields in the document.

To maintain Sync compatibility, the expression must be a boolean literal (either true or false).

Document-level write permissions take priority over any field-level permissions. If a role has document-level write permissions, it applies to all fields in the document. Write permissions specified by fields or additional_fields do not override document-level write permissions.

To define a default fallback alongside field-level rules, leave write undefined and use additional_fields.

You can use expansions like %%root and %%prevRoot in write JSON expressions.

Important

Implicit Read Permission

Any time a role has write permission for a particular scope it also has read permission even if that is not explicitly defined.

insert
object?
Default: true

An expression that evaluates to true if the role has permission to insert a new document into the collection.

App Services only evaluates this expression for insert operations and only after determining that the role has write permission for all fields in the new document.

delete
object?
Default: true

An expression that evaluates to true if the role has permission to delete a document from the collection.

App Services only evaluates this expression for delete operations and only after determining that the role has write permission for all fields in the document to be deleted.

search
Boolean
Default: true

An expression that evaluates to true if the role has permission to search the collection using Atlas Search.

Important

App Services performs $search operations as a system user and enforces field-level rules on the returned search results. This means that a user may search on a field for which they do not have read access. In this case, the search is based on the specified field but no returned documents include the field.

fields
Document
Default: {}

A document where each key corresponds to a field name, and each value defines the role's field-level read and write permissions for the corresponding field in a queried document.

To maintain Sync compatibility, the inner read and write expressions must be boolean literals (either true or false).

"fields": {
  "<Field Name>": {
     "read": { Expression },
     "write": { Expression },
     "fields": <Fields Document>
  },
  ...
}

Note

Permission Priority

Document-level read or write permissions override all field-level permissions of the same type. If permissions are defined for a field that contains an embedded document, those permissions override any permissions defined for the document's embedded fields.

fields.<Field Name>.read
object?
Default: false

An expression that evaluates to true if the role has permission to read the field.

To maintain Sync compatibility, the expression must be a boolean literal (either true or false).

fields.<Field Name>.write
object?
Default: false

An expression that evaluates to true if the role has permission to add, modify, or remove the field.

To maintain Sync compatibility, the expression must be a boolean literal (either true or false).

fields.<Field Name>.fields
Document
Default: {}

A fields document that defines read and write permissions for fields that are embedded within this field in a queried document.

See the Field-level Permissions for Embedded Documents role pattern for more information.

additional_fields
Document
Default: {}

A document that defines the role's field-level read and write permissions for any fields in a queried document that don't have explicitly defined permissions in the fields document.

To maintain Sync compatibility, the inner read and write expressions must be boolean literals (either true or false).

"additional_fields": {
  "read": { Expression },
  "write": { Expression }
}

additional_fields.read
object?
Default: false

An expression that evaluates to true if the role has permission to read any field that does not have a field-level permission definition in fields.

To maintain Sync compatibility, the expression must be boolean (either true or false).

additional_fields.write
object?
Default: false

An expression that evaluates to true if the role has permission to add, modify, or remove any field that does not have a field-level permission definition in fields.

To maintain Sync compatibility, the expression must be boolean (either true or false).

schema

Document

A document schema. The root level schema must be an object schema, which has the following form:

{
  "bsonType": "object",
  "properties": {
    "<Field Name>": <Schema Document>
  }
}

filters

Array<Document>

An array of Filter configuration documents, which have the following form:

{
  "name": "<Filter Name>",
  "apply_when": { Expression },
  "query": { MongoDB Query },
  "projection": { MongoDB Projection }
}

Field

Description

name

string

Required. The name of the filter. Filter names are useful for identifying and distinguishing between filters. Limited to 100 characters or fewer.

apply_when

object

An expression that determines when this filter applies to an incoming MongoDB operation.

Important

Atlas App Services evaluates and applies filters before it reads any documents, so you cannot use MongoDB document expansions in a filter's Apply When expression. However, you can use other expansions like %%user, %%values, and %function.

query
object
Default: {}

A MongoDB query that App Services merges into a filtered operation's existing query.

Example

A filter withholds documents that have a score below 20 using the following query:

{ "score": { "$gte": 20 } }

projection
object
Default: {}

A MongoDB projection that App Services merges into a filtered operation's existing projection.

Important

Projection Conflicts

MongoDB projections can be either inclusive or exclusive, i.e. they can either return only specified fields or withhold fields that are not specified. If multiple filters apply to a query, the filters must all specify the same type of projection, or the query will fail.

Example

A filter withholds the _internal field from all documents using the following projection:

{ "_internal": 0 }

External Services

3rd party services are defined in the /services directory. Each service maps to its own sub-directory with the same name as the service.

Each service directory contains the following:

config.json: a service configuration file
/rules: a sub-directory of service rule configurations
/incoming_webhooks: a sub-directory of webhook configurations (if the service supports webhooks, i.e. HTTP, GitHub, or Twilio)

yourRealmApp/
└── services/
    └── <services name>/
        ├── config.json
        ├── incoming_webhooks/
        │   ├── config.json
        │   └── source.js
        └── rules/
            └── <rule name>.json

Service Configuration

config.json

{
  "id": "<Service ID>",
  "name": "<Service Name>",
  "type": "<Service Type>",
  "config": {
    "<Configuration Option>": <Configuration Value>
  },
  "secret_config": {
    "<Configuration Option>": "<Secret Name>"
  },
}

Field	Description
`id` String	A string that uniquely identifies the service. Atlas App Services automatically generates a unique ID for a service when you create it.
`name` String	The name of the service. The name may be at most 64 characters long and can only contain ASCII letters, numbers, underscores, and hyphens.
`type` String	The type of the service. Valid Options: `"http"` `"aws"` `"twilio"` `"github"` `"gcm"`
`config` Document	A document with fields that map to additional configuration options for the service. The exact configuration fields depend on the service `type`. HTTP Service Configuration AWS Service Configuration Twilio Service Configuration GitHub Service Configuration
`secret_config` Document	A document where each field name is a private configuration field for the service and the value of each field is the name of a Secret that stores the configuration value.

Service Rules

Rules for a specific external service are defined in the /<service name>/rules sub-directory.

Each rule maps to its own JSON file with the same name as the rule.

<rule name>.json

{
  "id": "<Rule ID>",
  "name": "<Rule Name>",
  "actions": ["<Service Action Name>"],
  "when": <JSON Rule Expression>
}

Field	Description
`id` String	A string that uniquely identifies the rule. App Services automatically generates a unique ID for a rule when you create it.
`name` String	The name of the service rule. The name may be at most 64 characters long and can only contain ASCII letters, numbers, underscores, and hyphens.
`actions` Array<String>	A list of service actions that the rule applies to. The specific actions available depend on the service `type`.
`when` Document	A rule expression that evaluates to `true` when the rule applies to a given request.

Incoming Webhooks

Incoming webhooks for a specific service are defined in the /<service name>/incoming_webhooks/ sub-directory.

Incoming webhooks use the same configuration format as function but have additional configuration parameters.

Configuration

config.json

{
  "id": "<Function ID>",
  "name": "<Function Name>",
  "private": <Boolean>,
  "can_evaluate": <Rule Expression>,
  "disable_arg_logs": <Boolean>,
  "run_as_system": <Boolean>,
  "run_as_user_id": "<App Services User ID>",
  "run_as_user_id_script_source": "<Function Source Code>",
  "respond_result": <Boolean>,
  "options": {
    "httpMethod": "<HTTP Method>",
    "validationMethod": "<Webhook Validation Method>",
    "secret": "<Webhook Secret>"
  }
}

Field

Description

id

String

A value that uniquely identifies the function. App Services automatically generates a unique ID for a function when you create it.

name

String

The name of the function. The name must be unique among all functions in your application.

private

Boolean

If true, this function may only be accessed from incoming webhooks, rules, and named functions.

can_evaluate

Document

A rule expression that evaluates to true if the function is allowed to execute in response to a given request.

disable_arg_logs

Boolean

If true, App Services omits the arguments provided to a function from the function execution log entry.

run_as_system

Boolean

If true, the webhook function runs as the system user. This overrides any values defined for run_as_user_id and run_as_user_id_script_source.

run_as_user_id

String

The unique ID of a App Services User that the function always executes as. Cannot be used with run_as_user_id_script_source.

run_as_user_id_script_source

String

A stringified function that runs whenever the webhook is called and returns the unique ID of a App Services User that the function executes as. Cannot be used with run_as_user_id.

respond_result

Boolean

If true, App Services includes the webhook function return value as the body of the HTTP response it sends to the client that initiated the webhook request.

options

Document

A document that contains configuration options for the webhook.

{
  "httpMethod": "<HTTP Method>",
  "validationMethod": "<Webhook Validation Method>",
  "secret": "<Webhook Secret>"
}

Field	Description
`httpMethod` String	The HTTP method type that the webhook accepts. Incoming webhook requests must use this method.
`validationMethod` String	The name of the request validation method that the webhook uses. Valid options: `"VERIFY_PAYLOAD"` `"SECRET_AS_QUERY_PARAM"` `"NO_VALIDATION"`
`secret` String	The secret value used to validate incoming webhook requests.

Source Code

source.js

exports = function() {
  // webhook function code
};

Triggers

Triggers are defined in your application's /triggers directory.

Each trigger is defined in its own JSON file with the same name as the trigger.

yourRealmApp/
└── triggers/
    └── <trigger name>.json

Configuration

<trigger name>.json

{
  "id": "<Trigger ID>",
  "name": "<Trigger Name>",
  "type": "<Trigger Type>",
  "function_name": "<Trigger Function Name>",
  "config": {
    "<Configuration Option>": <Configuration Value>
  },
  "disabled": <Boolean>,
}

Field	Description
`id` String	A string that uniquely identifies the Trigger. Atlas App Services automatically generates a unique ID for a trigger when you create it.
`name` String	The name of the Trigger. The name may be at most 64 characters long and can only contain ASCII letters, numbers, underscores, and hyphens.
`type` String	The type of application event that the trigger listens for. Valid Options: `"DATABASE"` `"AUTHENTICATION"` `"SCHEDULED"`
`function_name` String	The name of the Atlas Function that the Trigger executes whenever it fires. The Trigger automatically passes arguments to the function depending on the Trigger `type`.
`config` Document	A document with fields that map to additional configuration options for the trigger. The exact configuration fields depend on the trigger `type`. Database Trigger Configuration Authentication Trigger Configuration Scheduled Trigger Configuration
`disabled` Boolean	If `true`, the trigger will not listen for any events and will not fire.

Hosting

Files that you want to host on Atlas App Services should be included in your application's /hosting directory. Each file will be uploaded with the metadata defined in metadata.json.

You can configure the metadata for each hosted file in metadata.json. This metadata configuration file is an array of documents that each correspond to a single hosted file's metadata attributes.

yourRealmApp/
└── hosting/
    ├── metadata.json
    └── files/
        └── <files to host>

Metadata Configuration

metadata.json

[
  {
    "path": "<File Resource Path>",
    "attrs": [{
      "name": "<Attribute Type>",
      "value": "<Attribute Value>"
    }]
  }
]

Field

Description

path

String

The resource path of the file.

attrs

Array<Document>

An array of documents where each document represents a single metadata attribute. Attribute documents have the following form:

Metadata Attribute Document

{
  "name": "<Attribute Type>",
  "value": "<Attribute Value>"
}

Field	Description
`name` String	The name of the metadata attribute. This should be one of the file metadata attributes that App Services supports.
`value` String	The value of the metadata attribute.

Note

If you do not specify a Content-Type metadata attribute for a hosted file, Atlas App Services will attempt to automatically add a Content-Type attribute to it based on the file extension.

For example, App Services would automatically add the attribute Content-Type: application/html to the file myPage.html.

Values

Values are defined in your application's /values directory.

Each value is defined in its own JSON file named after the value.

yourRealmApp/
└── values/
    └── <value name>.json

Configuration

<value name>.json

{
  "id": "<Value ID>",
  "name": "<Value Name>",
  "from_secret": <boolean>,
  "value": <Stored JSON Value|Secret Name>
}

Field	Description
`id` String	A string that uniquely identifies the value. Atlas App Services automatically generates a unique ID for a value when you create it.
`name` String	A unique name for the value. This name is how you refer to the value in functions and rules.
`from_secret` Boolean	Default: `false`. If `true`, the value exposes a Secret instead of a plain-text JSON value.
`value` String, Array, or Object	The stored data that App Services exposes when the value is referenced. If `from_secret` is `false`, `value` can be a standard JSON string, array, or object. If `from_secret` is `true`, `value` is a string that contains the name of the Secret that the value exposes.

Back

v20210101

App Metrics