If you have multiple MongoDB Atlas Triggers connected to AWS EventBridge, it can be difficult to tell which EventBridge partner event source belongs to which MongoDB collection or database.
For example, you may see an event source similar to:
aws.partner/mongodb.com/stitch.trigger/61d2ac6f624571ca88cfd71a
The question is: Can this 24-character identifier tell you which MongoDB collection or cluster the trigger belongs to?
The short answer is: the identifier itself does not contain the collection name. You need to map the trigger ID back to the corresponding MongoDB Atlas Trigger or inspect the event data.
Why Is the MongoDB Collection Name Not Clearly Visible?
1. The 24-Character Value Is the Trigger ID
The final 24-character value, such as:
61d2ac6f624571ca88cfd71a
should be treated as the unique ID of the MongoDB Atlas App Services Trigger.
It is not an encoded version of the MongoDB collection or cluster name. MongoDB’s App Services API identifies a trigger using its unique _id, while the database and collection are stored separately in the trigger configuration.
Therefore, you should not try to decode the 24-character value to discover the collection name.
2. EventBridge Uses a Partner Event Source
MongoDB Atlas can send Trigger events to an AWS EventBridge partner event source. AWS treats this as a partner-provided event source rather than displaying MongoDB’s internal database metadata directly in the EventBridge resource name.
This is why multiple MongoDB triggers can appear difficult to distinguish when you manage several collections.
How to Identify the Correct MongoDB Collection
Method 1: Match the Trigger ID in MongoDB Atlas
The most reliable approach is to go back to the MongoDB Atlas App Services configuration where the trigger was created.
- Open your MongoDB Atlas project.
- Open the relevant App Services application.
- Go to Triggers.
- Locate the trigger corresponding to the EventBridge source.
- Check its configuration to determine the database and collection it watches.
MongoDB’s Trigger configuration contains separate database and collection values. The collection field specifies the collection that the database trigger listens to.
Pro Tip: If you have many triggers, copy the 24-character Trigger ID from the EventBridge source and look for the same ID in your MongoDB Atlas/App Services trigger information. If your Atlas UI provides a trigger search/filter, using the ID there can make the matching trigger easier to locate.
Method 2: Check the Event Payload
Another practical way to identify the collection is to inspect an actual event generated by the MongoDB Trigger.
MongoDB change events contain namespace information such as:
{
"ns": {
"db": "my_database",
"coll": "orders"
}
}
The values indicate:
Database: ns.db
Collection: ns.coll
MongoDB’s own EventBridge documentation also demonstrates accessing the database and collection from the change event using:
changeEvent.ns.db
changeEvent.ns.coll
If your event reaches an AWS Lambda or another downstream service, inspect the actual event structure before writing code against a specific JSON path.
Important: If you use an EventBridge Input Transformer or otherwise modify the event before it reaches your target, the original event structure may no longer be available in the same form. Always check the payload received by your target.
What About the Cluster Name?
The collection and database information can identify the MongoDB namespace, but the EventBridge partner event source name should not be assumed to contain the human-readable MongoDB cluster name.
The trigger configuration links the trigger to a MongoDB data source through a service_id, while the database and collection are represented separately in the trigger configuration.
Therefore, if you need to identify the exact MongoDB deployment or cluster, check the corresponding MongoDB Atlas data source/trigger configuration rather than trying to derive it from the EventBridge identifier.
How to Avoid This Confusion in the Future
If you manage many MongoDB collections, use descriptive names for your AWS resources.
For example:
mongodb-orders-rule
mongodb-users-rule
mongodb-products-rule
You can also use descriptive tags where supported:
Collection = orders
Environment = production
This makes it much easier to recognize the purpose of an EventBridge rule without having to investigate the partner event source every time.
Final Takeaway
The 24-character value shown at the end of the MongoDB EventBridge partner event source is useful for identifying the specific MongoDB Trigger, but it should not be treated as an encoded collection or cluster name.
If you need to determine which collection a trigger belongs to:
1.Match the Trigger ID with the corresponding MongoDB Atlas Trigger.
2.Check the Trigger configuration for the database and collection.
3.Inspect an actual event payload and check its namespace information when available.
4.For the underlying deployment/cluster, check the MongoDB Atlas data source configuration.
The important point is that the collection name is not something you should try to derive by decoding the EventBridge resource identifier. Instead, use the Trigger ID as a reference and map it back to the MongoDB Atlas configuration or event data.