We got our connector rejected. It was the best product spec we received all year.

Why do apps get rejected from marketplaces?

We built a connector so a site owner could drop our analytics onto their site in a click, without touching code. We were proud of it. It worked in every test we ran. We submitted it.

It came back rejected.

The findings were specific, and they were fair. Among them: our loader pulled a remote SDK from an unpinned URL. We were reading a signed-in member’s email from the host page’s DOM and storage. Autocapture started firing before the visitor had consented. We were monkey-patching host globals, wrapping fetch and XHR to observe traffic. We shipped an iframe we did not strictly need. Our cookie scope and retention were broader than the job required. Marketing attribution was on by default.

Read individually, each one is a line item. Read together, they are a single coherent argument about what kind of software is allowed to run on other people’s sites. That argument is correct. Most apps get rejected not because the marketplace is difficult, but because the app was built as though it owned the environment it was a guest in.

First-party or third-party — what is the difference?

This is the distinction the whole story turns on, and it is the one we had not drawn sharply enough.

Everything in the rejection maps cleanly onto that second column. Reading a member’s email from the DOM is fine when it is your own member; it is an overreach when it is a stranger’s customer on a stranger’s site. Wrapping the host’s fetch is a reasonable convenience in your own app and a violation of trust in someone else’s. The behaviours were not wrong in the abstract. They were wrong for a guest, and a mature marketplace exists precisely to enforce that line on behalf of people who cannot audit every app they install.

Why marketplace rules are actually good for you

It would be easy to frame strict review as friction. We would argue the opposite, and not to be diplomatic.

Left alone, we would never have written the document the reviewer wrote for us. We would have kept shipping the powerful version because it worked and because nobody was stopping us. The review was an expert, adversarial reading of our own product from the one perspective we structurally could not hold — the perspective of the site owner’s customer, and the site owner’s own liability. That is genuinely hard to buy. Here it arrived as an email.

So we stopped treating the rejection as a verdict and started treating it as a backlog. Each finding became a ticket. The remote loader got pinned. The email-from-DOM read got removed. Autocapture moved behind consent. The fetch and XHR wrapping came out. The iframe went. Cookie scope and retention were cut to what the job needs. Marketing attribution defaulted off. None of it was busywork; every item made the product safer to run somewhere we did not control.

How the restrictions became the reason to upgrade

Here is the part we did not expect: the constraint clarified our product line instead of narrowing it.

A guest-grade build and an owner-grade build are genuinely different products for genuinely different situations, and pretending they were the same was our original mistake. So we shipped both. Marketplace mode is the lean, compliant guest: consent-first, minimal footprint, no host tampering, pinned dependencies — the right default for someone installing analytics onto a site they built for a client. Direct install is the full first-party experience for a developer putting our SDK into their own application, where the extra power is theirs to wield.

And this matters to us: the marketplace version honestly tells users the fuller one exists, and points them to it when they have outgrown the guest footprint. The restriction did not cost us the powerful build. It gave us an honest reason to offer two, and a clean way to describe which is which.

The consent banner is the small emblem of the whole shift. The review required one. We could have shipped the flat, grudging default. Instead we made it something the site owner is happy to show their visitors, rather than a compliance tax bolted to the page. A required control became a feature.

What we learned

Submit approval-grade the first time. The guidelines are the spec — they are published before you write a line of code, and reading them as requirements rather than as fine print is the whole discipline. A rejection email should never be a surprise; if it is, it means you treated the rules as an obstacle to clear later instead of the definition of done up front. We know this because we did not do it, and the review taught us for free.

Know whether you are the owner or the guest, and build for the seat you are actually in.

We had one product doing both jobs and getting the guest job wrong. The rejection did not break our product. It finished designing it.