This repo explains how to set up an Azure Function as an alternative to the MongoDB Atlas Data API. You can deploy the Azure Function App in a few clicks and use the Azure Function URL and Function App key instead of the Atlas Data API base URL and API key. It describes the Azure Function-based replacement solution and alleviates the burden on developers to build and deploy the function code manually.

Architecture

The architecture diagram above shows that when an API request is made to the Azure Function URL, authorized by the API key, the corresponding MQL is executed based on the operation in the URL. An example Azure Function URL is: https://<azure function name>.azurewebsites.net/api/mdb_dataapi/action/{operation}. The URL contains the operation, which indicates which API is invoked (findOne, find, insertOne, insertMany, deleteOne, deleteMany, updateOne, updateMany, or aggregate), and the corresponding Python SDK code is executed using the parameters passed in the request body. The results of the MQL operation are then returned to the application.

Prerequisites

1. Configure Atlas Environment

Register for a new Atlas Account here. Follow steps from 1 to 4 (Create an Atlas account, Deploy a Free cluster, Add your IP to the IP access list and Create a Database user) to set up the Atlas environment.

2. Set Up Azure Function as Atlas Data API To set up the Azure function which will host the code to act as Atlas Data APIs, we have two options - 1. Using GitHub Actions OR 2. Using Zip Deploy

   Choose the GitHub actions method, if you are able to fork the current repo, can have GitHub actions enabled in that repo and that you would want to add more APIs and prefer a CI/CD or DevOps set up out of the box. However, if you are looking for a quick and easy way of deployment and just need the Azure function set up to substitute the Atlas Data APIs, go with the Zip deploy option.

   Option 1: Set Up Azure function Using GitHub actions

   a. Fork the MongoDB repo. Note the new forked repo URL. If GitHub Actions is not enabled by default, enable it by going to Settings -> Actions -> General in your forked repo and selecting one of the options that allows actions or reusable workflows.

   b. Click the Deploy to Azure button below to create the Azure Function in your tenant.

   

   c. Select or Create your Resource group which will contain the Azure function and its associated components (App Service Plan, Storage Account and App Insights). You can keep the function name and SKU as the defaults or change if you like to follow some specific standards. We recommend that you add your Cluster name to the function app name so that its unique and easy to identify.

   Give the MongoDB connection URL for the cluster against which this Azure Function will run. This connection string will be saved as an environment variable. Give your forked repo URL as the GitHub repo. Select Create and it will create the Azure Function with the associated resources.

   Note that at this stage the function app is created, env variables are populated but the actual function is not yet deployed to the function app.

   d. To have GitHub actions run from your repo and deploy the function, get the publishing profile from your created Azure function.

   It gets downloaded, open it in a Text editor and copy all its contents.

   

   e. Go to your GitHub repo -> Settings -> Secrets and variables -> Actions Click New Respository secret and copy the entire value in your publishing profile to a new secret named "AZUREAPPSERVICE_PUBLISHPROFILE"

   f. Make a minor change in README.md and Commit Changes to trigger GitHub Actions, which will deploy the Python code to your Azure Function App. Now you should see the function available in the Function App and the code in function_app.py deployed.

   g. The GitHub Actions tab in your GitHub repo will show the deployment steps, including dependency installation, and the result of each step.

   Option 2: Set Up Azure function Using ZipDeploy

   a. Click the Deploy to Azure button below to create the Azure Function in your tenant.

   

   b. Select or create your resource group, which will contain the Azure Function and its associated components (App Service Plan, Storage Account, and Application Insights). You can keep the function name and SKU as the defaults or change them if you want to follow specific standards. We recommend that you add your cluster name to the Function App name so it is unique and easy to identify.

   Please DO NOT change the Package Url which points to the deployable zip file in this repo.

   Select Create and Azure will create the Function App and deploy the Azure Function along with the associated resources.

How to get credentials

Get the BaseUrl and API Key

a. From the Function App, select your function and click Get function URL. Copy the function URL from the beginning through /action/ as shown in the screenshot below. Replace {operation} with one of the supported API names depending on which API needs to be invoked. The valid operations are: findOne, find, insertOne, insertMany, deleteOne, deleteMany, updateOne, updateMany, and aggregate. This is the Base URL you will use to invoke the MongoDB CRUD and aggregate APIs.

b. Go to your Function App -> Under Functions -> App keys, and copy either the _master or default API key for your Azure Function. This is the API key you will use along with the Base URL to invoke the MongoDB CRUD and aggregate APIs.

Invoking the APIs using Azure function

Change your applications to use a URL format like https://<azure_function_name>.azurewebsites.net/api/mdb_dataapi/action/{operation} to invoke the Data APIs. Note that operation must be one of the supported values: findOne, find, insertOne, insertMany, deleteOne, deleteMany, updateOne, updateMany, or aggregate. For example, use https://<azure_function_name>.azurewebsites.net/api/mdb_dataapi/action/findOne to query the database and retrieve one record.

Also note that in the authorization headers you should add x-functions-key, and its value should be the API key of the Azure Function. The request body should include inputs such as database and collection, along with any operation-specific parameters. The dataSource field may be sent for compatibility with Atlas Data API clients, but this function uses the configured environment connection string to determine the MongoDB cluster.

See below curl as an example:

    curl --location 'https://<azure function name>.azurewebsites.net/api/mdb_dataapi/action/findOne' \
    --header 'Content-Type: application/json' \
    --header 'x-functions-key: < Azure function API key >' \
    --data '{
      "dataSource": "<cluster name>",
      "database": "< db name >",
      "collection": "< collection name >",
      "projection": {"<field name>":0}
    }'

Refer to the swagger file for the structure of each of the APIs.

ObjectId request and response behavior

This function now handles MongoDB ObjectId values explicitly so that queries and responses behave more like a MongoDB-aware API.

Responses

• Any MongoDB ObjectId returned by MongoDB is serialized as a string in the JSON response.
• This applies recursively, including nested documents and arrays, not just top-level _id fields.

Requests

• When filtering by _id, you may send either:
  • a plain string value, for example:
    • {"_id": "507f1f77bcf86cd799439011"}
  • extended JSON for an actual ObjectId, for example:
    • {"_id": {"$oid": "507f1f77bcf86cd799439011"}}
• Extended JSON {"$oid": "..."} is also supported in nested request payloads such as:
  • filters
  • update documents
  • insert documents
  • aggregation pipelines

Important note

• Plain string _id values are preserved as strings.
• The function does not automatically convert plain _id strings into ObjectId, because MongoDB collections may legitimately use string _id values.
• Only explicit {"$oid": "..."} wrappers are converted to MongoDB ObjectId values.

Known issues and limitations

Please follow this link for the known limitations with the Azure functions like time outs and other service limits for each resource plans.

Common errors and remedies

Typical API response codes apply here as well. Any 4XX errors indicate an issue with the client request. Make sure that the request body is valid JSON and that required fields such as database and collection are provided. Refer to this Postman Collection for examples. For 5XX errors, make sure the Azure Function is running and check its logs for more details.