Docs Menu

Docs HomeAtlas App Services

Data API Endpoints

On this page

  • When to Use the Data API
  • Base URL
  • Set Up the Data API
  • Authentication
  • Authorization
  • Response Type
  • Access Permissions
  • API Versions
  • Call a Data API Endpoint
  • Choose an API Version
  • Specify the Request Data Format
  • Choose a Response Data Format
  • Authenticate the Request
  • Authorize the Request

The Data API lets you securely read and write data using standard HTTPS requests. The API includes automatically generated endpoints that each represent a MongoDB operation. You can use the endpoints to create, read, update, delete, and aggregate documents in a MongoDB data source.

For example, this POST request stores a document in a linked cluster by calling the insertOne endpoint:

curl -s "" \
-H "Content-Type: application/ejson" \
-H "Accept: application/json" \
-H "apiKey: TpqAKQgvhZE4r6AOzpVydJ9a3tB1BLMrgDzLlBLbihKNDzSJWTAHMVbsMoIOpnM6" \
-d '{
"dataSource": "mongodb-atlas",
"database": "learn-data-api",
"collection": "hello",
"document": {
"text": "Hello, world!"
{ "insertedId": "5f1a785e1536b6e6992fd588" }

For a detailed API reference of all available endpoints, see the Data API OpenAPI Reference.

You can use the Data API to integrate with any app or service that supports HTTPS requests. For example, you might:

  • call the API from a serverless edge function

  • query Atlas from a mobile application

  • access test data and log events in a CI/CD workflow

  • integrate Atlas into a federated API gateway

  • connect from an environment not currently supported via a MongoDB Driver or Realm SDK

An operation called through an API endpoint will likely take longer than the corresponding MongoDB operation called through a connected MongoDB Driver. For high-load use-cases and latency sensitive applications, we recommend connecting directly to your database with a MongoDB driver. To learn more, visit the MongoDB Drivers documentation.

The Data API endpoints in an app share a base URL. The URL uses your App ID to uniquely point to your app and specifies which version of the Data API to call. Each endpoint has a unique URL formed by appending the endpoint's route to your app's base URL.

Globally deployed apps use the following format:

Endpoint Base URL (Global Apps):<App ID>/endpoint/data/<API Version>

Endpoints in a locally deployed app use a base URL specific to the app's deployment region (e.g.

Endpoint Base URL (Local Apps)
https://<Region>.<Cloud><App ID>/endpoint/data/<API Version>

You can configure the Data API for your app from the App Services UI or by deploying configuration files with App Services CLI:

Data API endpoints run in the context of a specific user, which allows your app to enforce rules and validate document schemas for each request.

By default, endpoints use Application Authentication, which requires each request to include credentials for one of your application users, like an API key or JWT. You can also configure other custom authentication schemes to fit your application's needs.

For examples of how to authenticate requests, see Authenticate Data API Requests.

You can require authenticated users to provide additional authorization information in each request. You define the authorization scheme for all generated Data API endpoints in your Data API configuration.

Endpoints natively support a set of built-in authorization schemes that use a secret string to prove that the request is authorized. You can also define a custom authorization scheme that you can use together with or instead of the built-in schemes.

Endpoints support the following built-in authorization schemes:

You can define a custom authorization expression to determine if an incoming authenticated request is allowed to run. The expression is evaluated for each request and must evaluate to true to allow the request. If the expression evaluates to false, the request is not authorized and fails with an error. Requests that fail authorization are not counted toward your App's billed usage.

Authorization expressions can use variables like %%user to authorize based on the calling user's data or %%request to make decisions based on the specifics of each incoming request.

To define a custom authorization scheme, specify the expression in your app's Data API configuration:

"can_evaluate": {
"%%request.requestHeaders.x-secret-key": "my-secret"

Endpoints can return data in one of two data formats, either JSON or EJSON.

By default, endpoints return JSON, which is a standard data format that is widely supported modern langauges and platforms. However, JSON cannot represent every data type that you can store in MongoDB and loses type information for some data types.

You can also configure endpoints to return EJSON, which uses structured JSON objects to fully represent the types that MongoDB supports. This preserves type information in responses but requires that your application understands how to parse and use EJSON.


The official MongoDB drivers include methods for working with EJSON. You can also download a standalone parser like bson on npm.

The Data API uses your app's data access rules to determine if a user can read and write data. To allow Data API requests to access a specific collection, you must first define rules for the collection.

You can also set up an IP Access List for additional security.

The Data API uses a built-in versioning scheme to upgrade endpoints over time while maintaining backwards compatibility. Incoming requests can specify which version of an endpoint to use in the request URL and the Data API can serve any version that you have enabled.

You must enable a new version before users can call endpoints with that version. You can always enable the most recent Data API version. However, you cannot enable an older version after a newer version has been released.

The following versions are currently supported:

  • beta

  • v1

You can call a Data API endpoint from any standard HTTP client. Each request can include configuration headers and arguments in the request body.

HTTP/1.1 or greater is required when making requests.

Data API requests specify which version of the API to use in the request URL. A request can specify any version that is enabled for your app.<App ID>/endpoint/data/<API Version>

Data API requests must include a Content-Type header to specify the data format used in the request body.

  • Use Content-Type: application/json to represent standard JSON types in a Data API request body.

  • Use Content-Type: application/ejson to represent standard JSON types and additional EJSON types in a Data API request body.

A request can include an Accept header to request a specific data format for the response body, either JSON or EJSON. If a request does not include a valid Accept header, the response uses the data format specified in your Data API configuration.

If an endpoint is configured to use Application Authentication then you must include a valid user access token or login credentials with every request.

In general, bearer authentication with an access token has higher throughput and is more secure than credential headers. Use an access token instead of credential headers when possible. The token lets you run multiple requests without re-authenticating the user. It also lets you send requests from a web browser that enforces CORS.

To use an access token, first authenticate the user through an App Services authentication provider. Then, get the access token returned from App Services and include it in the request's Authorization header using a Bearer token scheme. For more information on how to acquire and use an access token, see Bearer Token Authentication.

curl -s "" \
-H "Accept: application/json" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-d '{
"dataSource": "mongodb-atlas",
"database": "sample_mflix",
"collection": "movies",
"filter": {
"title": "The Matrix"

Alternatively, you can include valid login credentials for the user in the request headers.


Don't Use API Keys in User-Facing Clients

If you're authenticating from a browser or another user-facing client application, avoid using an API key to log in. Instead, use another authentication provider that takes user-provided credentials. Never store API keys or other sensitive credentials locally.

Depending on your Data API authorization configuration, your requests may need to include additional authorization information.

← Atlas Data API