Introducing the MongoDB Atlas Data API, Now Available in Preview

Emma Lullo and Sumedha Mehta
November 18, 2021 | Updated: June 3, 2022

As the leading data platform, MongoDB is hyper-focused on accelerating and simplifying how developers leverage their application data. This has led to the introduction of features like serverless instances and the Atlas Triggers that minimize the operational burden associated with traditional database workloads.

Today, we’re excited to announce the next step forward in this mission with the introduction of the MongoDB Atlas Data API – a fully managed, REST-like API for accessing your Atlas data. The Data API makes it easy to perform CRUD and aggregations on your data in minutes and allows you to query MongoDB from your backend in any language, without the need for drivers.

The next level of data access

Organizations are increasingly relying on operational data layers to build distributed architectures like microservices for their modern applications to speed-up development and stay competitive in rapidly changing markets. These stacks often require scalable, highly available, and secure access to the data layer.

The most popular way to architect these data services is to build APIs that communicate with MongoDB data over HTTPS using REST or similar protocols. However, creating a custom-built API typically takes a lot of time and effort. It's a painful process that introduces unnecessary operational burdens like provisioning additional servers, connection management, and scaling.

With the Atlas Data API, customers can generate a fully managed, REST-like API for their Atlas data in seconds. Developers no longer need to worry about the underlying infrastructuring of their APIs, and instead can enjoy the efficiency of intuitive, out-of-the box data access, while still being able to leverage the always-on and highly available qualities of Atlas as the underlying database.

This unlocks a whole new level of developer productivity for use cases that were previously time consuming to accomplish – such as building data-centric microservices, simplifying access from serverless functions, and integrating with third party services . The API even has built-in support for aggregation pipelines to use with services like Atlas Search.

Try the Atlas Data API

All customers now have the ability to enable the Data API for their Atlas deployment. We invite you to try it out today with a new or existing Atlas account.

It’s incredibly easy to get started: simply choose the cluster you’d like to connect to and generate an API key. That’s all it takes to set up and start accessing Atlas data.

Have questions? Check out our documentation or head over to our community forums to get answers from fellow developers.

What's next for the Atlas Data API

This preview release is just the beginning. Support for services like Data Lake and Serverless Instances will be added over the coming months. And, long term, we see the Data API as the next step in our journey to abstract and automate infrastructure decisions – to help developers build the future faster.

Atlas Data API documentation can be found here

← Previous

Simplifying Compliance with VComply & MongoDB

As businesses globally are facing external pressures to be more focused on privacy, security, and transparency, compliance management is needed now more than ever. With 200+ regulatory updates, 900 regulatory agencies, and the average cost of a non-compliance incident being $14 million, maintaining compliance is critical for every business, no matter the size. Tracking, maintaining, and proving compliance has traditionally been incredibly difficult, resource-intensive, and takes a significant time commitment. That's why one startup aims to simplify compliance by disrupting the antiquated industry. Enter VComply . Founded in 2019, VComply is a governance, risk management, and compliance (GRC) platform that enables its customers with a secure and easy-to-use solution. VComply is highly configurable to meet the specific needs of any organization without additional coding or infrastructure changes. The platform collects, organizes, analyzes, and automatically reports on GRC data inputted into the system to provide a high-level view of an organization's compliance posture at any given time. Combining that with the ability to surface detailed information on any control, VComply modernizes how people work and interact with GRC programs within their businesses. In this week's #BuiltWithMongoDB, we take a look at VComply to learn more about how they are truly helping organizations strengthen their risk and compliance management. We spoke with Harshvardhan Kariwala, CEO, and Ashish Jha, Vice President of Engineering at VComply to discuss the company's journey and how they decided to build with MongoDB. What inspired you to build the business? Harshvardhan: VComply is actually my third startup. At one of my previous companies, I had become hyper-focused on building the business, and I eventually lost sight of compliance. Operational functions fell through the cracks, and I ended up outsourcing our compliance programs to this corporate firm in Singapore. Fast forward a bit, they ended up forgetting to do a required compliance filing, and we ended up responsible for paying the non-compliance fines associated with that. One reporting misstep, and we were fined. That's what got me worried. We got lucky that was all that happened. It only took one time to inspire action. We then built an internal tool where the entire idea was around creating a culture of reporting excellence and internal accountability. After adopting our newly created tool, in 2018, we realized that we built a very robust solution to real day-to-day compliance problems. We thought, "Why don't we spin this off into its own product?" By that time, I was ready to get back into product development, and this was the perfect opportunity. In early 2019 we set up VComply. We quickly got our first customer, the City of Boston, and never looked back. So that's where VComply got its start. It was never meant to be sold as a product. It was more of an internal compliance tracking tool. That's how we entered the GRC space. What exactly does VComply do? What are some of its most useful product features? Harshvardhan: We help businesses be compliant, mitigate risk, and adopt a culture of transparency. If there isn't internal alignment within a company, no tool is going to help them. At its core, VComply is designed to be easy to use so that anyone in an organization can adopt a compliance-first mindset. By removing the traditional technological barriers, we found that businesses can realize the benefits quickly. That said, VComply serves as the single source of truth for everything GRC within an organization. Think tracking compliance obligations, compliance monitoring, automating activities, alerts and follow-ups, compliance evidence collection, audit trails, and more. Another popular piece of our tool is our enterprise risk management as well as policy management functionalities. You can monitor and manage risk programs, quickly identify risks, and start linking compliance obligations to mitigate that risk. What makes VComply stand out from its competitors? Harshvardhan: Most other solutions on the market require a compliance expert, are hard to navigate, and take a significant time commitment upfront to get up and running. We built VComply to be more practical and realistic with how people manage their compliance and risk programs today. VComply is easy to set up, simple to use for the end-user, and flexible to map to the specific controls a business needs to comply with without any additional coding. How did you decide to build with MongoDB? Ashish: Easy and intuitive search support, as well as indexing and automated performance suggestions, were the key drivers for us building with MongoDB. Also, training new developers is very straightforward. What has your experience been like scaling with MongoDB? Ashish: Scaling is pretty seamless with MongoDB. Setting up alerts and monitoring is very straightforward. We've had nothing but great experiences so far. Do you have a favorite technical book or podcast that you would recommend to other tech entrepreneurs? Harshvardhan: I would recommend The Great CEO Within: The Tactical Guide to Company Building by Matt Mochary. That's definitely a great read. This is a bit of an open questions, so feel free to interpret it how you'd like. What are you currently learning? Harshvardhan: That's a tough one. I think you're always learning so many different things on any given day that it's difficult to give one answer. Today, I'm learning marketing strategies, like demand gen as well as sales tactics to scale the business. Ashish: Primarily, I'm learning how engineering can augment and support other organizations within the company. Who are some tech leaders or entrepreneurs that you admire? Ashish: I do admire Jeff Bezos quite a bit. I admire the laser focus that he has and the clarity in terms of his reasoning. Harshvardhan: Elon Musk because of his ideas and execution. One thing that's great about him is how he executes his ideas flawlessly. Interested in learning more about MongoDB for Startups? Learn more about us here .

November 17, 2021

Next →

Retrieval Augmented Generation for Claim Processing: Combining MongoDB Atlas Vector Search and Large Language Models

Following up on our previous blog, AI, Vectors, and the Future of Claims Processing: Why Insurance Needs to Understand The Power of Vector Databases , we’ll pick up the conversation right where we left it. We discussed extensively how Atlas Vector Search can benefit the claim process in insurance and briefly covered Retrieval Augmented Generation (RAG) and Large Language Models (LLMs). MongoDB.local NYC Join us in person on May 2, 2024 for our keynote address, announcements, and technical sessions to help you build and deploy mission-critical applications at scale. Use Code Web50 for 50% off your ticket! Learn More One of the biggest challenges for claim adjusters is pulling and aggregating information from disparate systems and diverse data formats. PDFs of policy guidelines might be stored in a content-sharing platform, customer information locked in a legacy CRM, and claim-related pictures and voice reports in yet another tool. All of this data is not just fragmented across siloed sources and hard to find but also in formats that have been historically nearly impossible to index with traditional methods. Over the years, insurance companies have accumulated terabytes of unstructured data in their data stores but have failed to capitalize on the possibility of accessing and leveraging it to uncover business insights, deliver better customer experiences, and streamline operations. Some of our customers even admit they’re not fully aware of all the data in their archives. There’s a tremendous opportunity to leverage this unstructured data to benefit the insurer and its customers. Our image search post covered part of the solution to these challenges, opening the door to working more easily with unstructured data. RAG takes it a step further, integrating Atlas Vector Search and LLMs, thus allowing insurers to go beyond the limitations of baseline foundational models, making them context-aware by feeding them proprietary data. Figure 1 shows how the interaction works in practice: through a chat prompt, we can ask questions to the system, and the LLM returns answers to the user and shows what references it used to retrieve the information contained in the response. Great! We’ve got a nice UI, but how can we build an RAG application? Let’s open the hood and see what’s in it! Figure 1: UI of the claim adjuster RAG-powered chatbot Architecture and flow Before we start building our application, we need to ensure that our data is easily accessible and in one secure place. Operational Data Layers (ODLs) are the recommended pattern for wrangling data to create single views. This post walks the reader through the process of modernizing insurance data models with Relational Migrator, helping insurers migrate off legacy systems to create ODLs. Once the data is organized in our MongoDB collections and ready to be consumed, we can start architecting our solution. Building upon the schema developed in the image search post , we augment our documents by adding a few fields that will allow adjusters to ask more complex questions about the data and solve harder business challenges, such as resolving a claim in a fraction of the time with increased accuracy. Figure 2 shows the resulting document with two highlighted fields, “claimDescription” and its vector representation, “claimDescriptionEmbedding” . We can now create a Vector Search index on this array, a key step to facilitate retrieving the information fed to the LLM. Figure 2: document schema of the claim collection, the highlighted fields are used to retrieve the data that will be passed as context to the LLM Having prepared our data, building the RAG interaction is straightforward; refer to this GitHub repository for the implementation details. Here, we’ll just discuss the high-level architecture and the data flow, as shown in Figure 3 below: The user enters the prompt, a question in natural language. The prompt is vectorized and sent to Atlas Vector Search; similar documents are retrieved. The prompt and the retrieved documents are passed to the LLM as context. The LLM produces an answer to the user (in natural language), considering the context and the prompt. Figure 3: RAG architecture and interaction flow It is important to note how the semantics of the question are preserved throughout the different steps. The reference to “adverse weather” related accidents in the prompt is captured and passed to Atlas Vector Search, which surfaces claim documents whose claim description relates to similar concepts (e.g., rain) without needing to mention them explicitly. Finally, the LLM consumes the relevant documents to produce a context-aware question referencing rain, hail, and fire, as we’d expect based on the user's initial question. So what? To sum it all up, what’s the benefit of combining Atlas Vector Search and LLMs in a Claim Processing RAG application? Speed and accuracy: Having the data centrally organized and ready to be consumed by LLMs, adjusters can find all the necessary information in a fraction of the time. Flexibility: LLMs can answer a wide spectrum of questions, meaning applications require less upfront system design. There is no need to build custom APIs for each piece of information you’re trying to retrieve; just ask the LLM to do it for you. Natural interaction: Applications can be interrogated in plain English without programming skills or system training. Data accessibility: Insurers can finally leverage and explore unstructured data that was previously hard to access. Not just claim processing The same data model and architecture can serve additional personas and use cases within the organization: Customer Service: Operators can quickly pull customer data and answer complex questions without navigating different systems. For example, “Summarize this customer's past interactions,” “What coverages does this customer have?” or “What coverages can I recommend to this customer?” Customer self-service: Simplify your members’ experience by enabling them to ask questions themselves. For example, “My apartment is flooded. Am I covered?” or “How long do windshield repairs take on average?” Underwriting: Underwriters can quickly aggregate and summarize information, providing quotes in a fraction of the time. For example, “Summarize this customer claim history.” “I Am renewing a customer policy. What are the customer's current coverages? Pull everything related to the policy entity/customer. I need to get baseline info. Find relevant underwriting guidelines.” If you would like to discover more about Converged AI and Application Data Stores with MongoDB, take a look at the following resources: RAG for claim processing GitHub repository From Relational Databases to AI: An Insurance Data Modernization Journey Modernize your insurance data models with MongoDB and Relational Migrator

April 18, 2024