The MongoDB Atlas Data API is fundamentally a REST API that lets you interact with your Atlas data without needing to install or manage any MongoDB drivers.

Let’s see it in action. Imagine you have a simple MongoDB collection named users in a database called mydatabase, and you want to find all users whose age is greater than 25.

Here’s how you’d construct a POST request to the Data API:

curl -X POST 'https://data.mongodb-api.com/app/<your-app-id>/endpoint/data/v1/action/find' \
-H 'Content-Type: application/json' \
-H 'api-key: <your-api-key>' \
-d '{
  "database": "mydatabase",
  "collection": "users",
  "filter": {
    "age": { "$gt": 25 }
  }
}
'

Replace <your-app-id> with your Atlas App Services App ID and <your-api-key> with your Data API key. The response will be a JSON object containing the documents that match your query:

{
  "documents": [
    {
      "_id": "60d5ec49f1f2f3b4c5d6e7f8",
      "name": "Alice",
      "age": 30
    },
    {
      "_id": "60d5ec49f1f2f3b4c5d6e7f9",
      "name": "Bob",
      "age": 28
    }
  ],
  "continuation": null,
  "fetched_count": 2
}

This demonstrates the core idea: you’re sending a JSON payload describing your desired operation (a find in this case) to a specific API endpoint, and receiving JSON back. It abstracts away the network protocols, BSON serialization, and connection pooling that drivers handle.

The problem this solves is simplifying access to MongoDB, especially in environments where installing drivers is difficult or undesirable. Think serverless functions, edge computing, or even simple web frontends that need to interact with data without the overhead of a full driver. It democratizes access to your data.

Internally, your Atlas App Services application acts as a proxy. When you send a request to the Data API endpoint, App Services receives it, authenticates it using your API key, parses the JSON payload, translates it into a native MongoDB query, executes it against your Atlas cluster, and then serializes the results back into JSON to send to your client. This means your App Services application needs to be configured to allow access to the specific database and collection you’re targeting.

The exact levers you control are primarily within the App Services UI. You define "API Endpoints" which map HTTP methods (GET, POST, PUT, DELETE) and paths to specific "Service Functions." These Service Functions are written in JavaScript (or TypeScript) and can directly call MongoDB services using the SDK. The Data API is a pre-built set of endpoints that abstracts away this Service Function creation for common CRUD operations. You configure which databases and collections are accessible through the Data API, and what authentication mechanisms (like API keys) are allowed.

What most people don’t realize is that the Data API endpoints are themselves implemented as Service Functions within your App Services application. You can view and even customize the underlying JavaScript code for these built-in actions if you need more complex logic than a direct find, insertOne, or updateOne provides, while still leveraging the Data API’s authentication and endpoint structure. This allows for powerful, custom serverless logic without managing any custom API endpoints from scratch.

The next step is exploring how to use the Data API for more complex operations like aggregations or managing custom authentication flows.

Want structured learning?

Take the full Mongodb course →