Skippr Docs

Appearance

How MongoDB Source Authentication Works in Skippr ​

June 2026

MongoDB source authentication in Skippr is connection-string based, which keeps setup compact but makes the exact URI and auth database details matter more than people expect.

Short Answer ​

MongoDB source authentication in Skippr is driven by a single connection_string plus the explicit database and collection you want to read. The docs recommend putting that URI in MONGODB_CONNECTION_STRING, which is especially useful because MongoDB authentication often depends on details hidden inside the URI itself, such as credentials, auth database, replica-set options, and TLS parameters.

That means a healthy source is more specific than "the URI works." If the connection string authenticates as one user but the source points at database app and collection events, the same user still needs read access there. A URI that logs in successfully against one auth database can still be the wrong auth model for the collection the pipeline is supposed to ingest.

Why Teams Struggle with This ​

MongoDB auth problems often look like scope problems because the URI carries so much responsibility. The docs keep the model simple, but the operator still has to make sure the connection string, database, collection, and runner network access all line up.

  • The connector authenticates with a MongoDB connection URI, not separate username and password fields.
  • The docs recommend environment interpolation for connection_string, which is safer and easier to rotate.
  • The MongoDB user needs read access to the selected database and collection after authentication succeeds.
  • If the long-term plan includes CDC, the docs also send you to change-stream requirements that sit beyond simple collection-read authentication.

How Skippr Handles It ​

Skippr keeps the connector compact without hiding what matters. You can see the auth surface quickly: one URI, one database, one collection, and an optional filter. That is enough to tell whether the source is a clean collection reader or a vague connection that has not been scoped yet.

A good first source is easy to explain to another engineer. "We read mongodb.app.events with the URI from MONGODB_CONNECTION_STRING" is much clearer than "we connected to MongoDB and hoped the right collection would show up."

  • Connection-string authentication through connection_string or ${MONGODB_CONNECTION_STRING}.
  • Explicit scope through separate database and collection fields after authentication.
  • A documented requirement that the user can read the selected collection from the runner environment.
  • A clean step-up path to CDC later without changing the base auth model for collection access.

What the First Useful Version Looks Like ​

The first useful version is one trusted connection string and one collection with known data. That proves the URI, permissions, and collection scope in one pass.

If authentication fails, inspect the URI as a whole before changing downstream logic. In MongoDB, the auth database and URI options are often the real cause.