# The MongoDB Atlas Data API Is Gone: What to Use Instead

> The Atlas Data API was removed on September 30, 2025. Here are the practical alternatives for apps, serverless code, scripts and quick data checks.

Source: https://bussolaformongo.app/blog/mongodb-data-api-alternatives/ · 2026-10-06

The **MongoDB Atlas Data API** let you read and write documents with a plain HTTPS request and an API
key. It was deprecated in September 2024 and removed on **September 30, 2025**, together with Custom
HTTPS Endpoints. If you are still looking for a **MongoDB Data API alternative**, the right
replacement depends on who was calling it. This guide groups the options by use case.

## What the Data API did, and why people loved it

The Data API exposed actions such as `findOne`, `find`, `insertOne`, `updateMany`, `deleteOne` and
`aggregate` as HTTPS endpoints. A request carried the data source, database, collection and a JSON
body with the filter or pipeline, and the response came back as JSON or Extended JSON.

Its appeal was that it worked **anywhere `fetch` works**:

- edge and serverless runtimes without outbound TCP;
- mobile apps and browser code;
- low-code tools, spreadsheets and webhooks;
- shell scripts and cron jobs using `curl`;
- developers checking data quickly without installing anything.

Each of those has a different best replacement.

## Option 1: your own API with the official driver

For application traffic, the long-term answer is a small service that uses an official driver and
exposes only the operations your clients need. This is also more secure than the Data API ever
was: instead of a key that can run arbitrary queries, clients call endpoints with fixed semantics
and your own authentication.

A minimal Node.js example:

```js
import express from 'express';
import { MongoClient, ObjectId } from 'mongodb';

const client = new MongoClient(process.env.MONGODB_URI); // create once, reuse
const orders = client.db('shop').collection('orders');
const app = express();

app.get('/orders/:id', async (req, res) => {
  if (!ObjectId.isValid(req.params.id)) return res.status(400).end();
  const order = await orders.findOne(
    { _id: new ObjectId(req.params.id) },
    { projection: { customer: 1, status: 1, total: 1 }, maxTimeMS: 2000 },
  );
  order ? res.json(order) : res.status(404).end();
});

app.listen(3000);
```

Three details that matter when replacing the Data API:

- **Create the client once.** A `MongoClient` manages a connection pool; creating one per request
  is the most common performance bug in migrations.
- **Bound every query** with a projection, a limit where relevant, and `maxTimeMS`, so a bad
  request can't run forever.
- **Decide how you serialize types.** The Data API could return Extended JSON (EJSON), which
  preserves `Int64`, `Decimal128` and dates. Plain `JSON.stringify` does not: `Long` values,
  decimals and `ObjectId`s change shape. If clients depended on exact types, use the driver's
  `EJSON.stringify` (from the `bson` package) and parse with `EJSON.parse` on the other side.

The same pattern works in any language with an official driver: Python with FastAPI, Go with
`net/http`, Java with Spring, NestJS on top of the Node driver.

## Option 2: serverless functions

If you liked the Data API because there was no server to run, serverless functions are the closest
match. AWS Lambda, Google Cloud Functions and Azure Functions all run the official drivers.

The rule that makes them work well: **initialize the client outside the handler**, so warm
invocations reuse the existing connection pool instead of opening new connections on every call.

```js
import { MongoClient } from 'mongodb';
const client = new MongoClient(process.env.MONGODB_URI);

export const handler = async (event) => {
  const n = await client.db('shop').collection('orders').countDocuments({ status: 'pending' });
  return { statusCode: 200, body: JSON.stringify({ pending: n }) };
};
```

Keep an eye on connection counts: many concurrent instances each open their own pool, and smaller
Atlas tiers have connection limits. A modest `maxPoolSize` per function instance helps.

**Edge runtimes** are trickier. Many of them don't allow arbitrary outbound TCP, which is exactly
why the Data API was popular there. Check your platform's documentation for TCP socket support
before porting; if it isn't available, call a regular serverless function or API from the edge.

## Option 3: a REST layer in front of MongoDB

If you have many consumers built around generic "run this query over HTTP" calls and rewriting them
all isn't realistic, a generic REST layer can sit in front of your database. Open-source projects
such as RESTHeart expose collections over HTTP with their own authentication and permission models.

This buys time, but think carefully before re-creating "any query over HTTP" in production: the
replacement inherits the same security trade-offs that made purpose-built endpoints the better
design.

## Option 4: scripts and scheduled jobs

For `curl` one-liners in cron jobs and CI, the simplest replacement is usually `mongosh` with
`--eval` or a script file:

```bash
mongosh "$MONGODB_URI" --quiet --eval 'db.orders.countDocuments({ status: "pending" })'
```

For anything longer than a line, a short script in Node or Python with the official driver is easier
to maintain than shell quoting, and you get real error handling.

## Option 5: humans who just want to look at data

A surprising amount of Data API traffic came from people, not programs: a bookmarked request in an
HTTP client, a spreadsheet pulling a few numbers, a quick check from a phone. For these:

- **On a computer:** MongoDB Compass, `mongosh`, or the Data Explorer in the Atlas UI.
- **On a phone:** a native client that connects directly. [Bussola](/) embeds the official MongoDB
  Rust driver on iOS, so you can run filters, edit documents and build aggregation pipelines over
  a direct TLS connection, with no API in between. We explain how that works in
  [How to Query MongoDB From an iPhone Without a Backend](/blog/query-mongodb-from-iphone-without-backend/).

## A migration checklist

1. **Inventory every caller.** Search code, low-code tools, scheduled jobs and saved HTTP requests
   for the Data API base URL and API keys.
2. **Map actions to driver calls.** `findOne`, `find`, `insertOne`, `updateOne`, `aggregate` and
   the rest map one to one to driver methods with the same names.
3. **Check types end to end**, especially `Int64`, `Decimal128`, dates and `ObjectId`.
4. **Replace API keys with real authentication** and give each service a database user with the
   least privilege it needs.
5. **Revoke the old keys** and remove unused App Services apps so nothing stale remains.
6. **Load test** the new endpoints with realistic concurrency, and watch connection counts in the
   Atlas metrics.

## Bottom line

There is no single drop-in substitute for the Data API, and that's mostly a good thing. Applications
should get a small, purpose-built API or serverless function using an official driver. Scripts
should use `mongosh` or a short driver script. People who just need to see their data should use a
proper client, on the desktop or on the phone.