How Landed Keeps Connectors From Breaking

Every data team has a version of the same story: you wake up Monday morning to a Slack message that says the Salesforce sync stopped working on Friday. The sales team has been making decisions on stale data all weekend. Someone has to dig into the connector, figure out what changed, and fix it — before they can get back to their actual work.

This is the default state of data integration. And it's broken.

Why Connectors Break

Connectors are wrappers around third-party APIs. Those APIs change. Fields get renamed, deprecated, or removed. Authentication schemes evolve. Rate limits tighten. Pagination patterns shift. Every one of these changes is a silent landmine for a connector built to the old spec.

Traditional ETL vendors like Fivetran maintain connectors with human engineers. A dedicated team watches for API changes, files tickets, and ships patches — eventually. In the meantime, your pipeline is silently failing or returning partial data. The average time-to-patch for an API-breaking change at a major ETL vendor is measured in weeks, not hours.

Even worse: most failures aren't obvious. A connector doesn't crash with an error — it just quietly stops returning new records because the cursor field was renamed. Your dashboard looks fine. The row count ticks up normally. But the data is wrong.

The Landed Approach

Landed was built with a different assumption: connectors will break, so the system needs to detect and repair them automatically.

Here's how it works.

Continuous schema validation. Every sync run, Landed compares the fields returned by the source API against the expected schema. If a field disappears or a new required field appears, it's flagged immediately — before any bad data reaches your destination.

Automated diagnostics. When a connector fails, our system analyzes the error: the HTTP response, the request that triggered it, and the connector's source code. It identifies whether the failure is a temporary API hiccup, a credential issue, or an actual API change requiring a code fix.

Automated repair. For known failure patterns — renamed fields, deprecated endpoints, updated OAuth flows — fixes are developed and deployed without human intervention. The repaired connector is tested against the live API before being promoted.

Schema evolution at the destination. When the source schema changes legitimately (a new column was added), Landed propagates the change to your destination automatically. No ALTER TABLE statements to write. No migrations to coordinate. Your destination stays in sync with reality.

What This Looks Like in Practice

When Salesforce deprecated the Metadata field on the Task object last year, traditional ETL pipelines started silently dropping rows that included it. Connectors that used the field as a filter broke outright.

Landed caught the change within the first failed sync. Our system identified the deprecated field, generated a patch that removed the dependency, and re-ran the sync — all within 15 minutes of the first failure. No human involved. No Slack message Monday morning.

The Bigger Picture

The goal isn't just to fix connectors faster. It's to get to a world where connector maintenance isn't a recurring cost at all.

Every connector in Landed is defined in a way that our engineering team can read, understand, and modify. The schemas are explicit. The extraction logic is structured. The test coverage is comprehensive. When an API changes, the system has everything it needs to diagnose the problem and propose a fix — without a human having to re-read the API docs from scratch.

This is what it means to have managed data infrastructure. Not a tool that writes code for you to review, but infrastructure that keeps your pipelines running while you focus on what the data actually means.

---

Landed is free to try for 14 days. If you have a connector that keeps breaking, start here.