FAQ

No, and this is the most important distinction. Dependabot watches the packages listed in your manifest: your npm, pip, or Go dependencies. Those live inside your repo and GitHub already owns that lane well. Sunset watches the providers you call over HTTP that never show up in a manifest at all, starting with the Shopify Admin API. Different surface, different problem.

No. Every PR Sunset opens is a draft, and nothing merges without a human approving it. That's not a v1 limitation we're planning to remove later, it's a deliberate design choice. We'd rather be a tool you trust than one that's fast and occasionally wrong in your prod branch.

Every migration is applied to an isolated branch and run against your own repo's test suite, pointed at the new API version, before a PR ever opens. If your tests are thin, that's a real limit worth knowing: a green result means "passes what you already test for," not "provably correct." We say so in the report rather than overselling a green checkmark. Where a call site is ambiguous, we flag it low-confidence instead of guessing.

Shopify Admin API first, because Shopify force-sunsets a version roughly every twelve months, which makes the breakage frequent and dated rather than occasional. Google Ads and Meta Marketing API are next, then Stripe.

We only raise a flag when we're confident a call site actually touches what's changing. If the documentation is ambiguous, Sunset marks the case low-confidence and tells you why, rather than writing a migration against a guess.

That's the actual hard part of this product, and yes: Sunset uses an AST parser that follows the call graph through your own wrapper classes and helper functions, not a regex search against literal API calls. If it can't resolve a call site with confidence, it says so instead of pretending it found nothing.

No. Verification runs against a test environment pinned to the new API version, not your live store. Sunset needs read access to your repo code and write access to open a branch and a draft PR; it doesn't need your store's admin credentials.

Source code, to find and match call sites, and your test suite, to verify a migration before proposing it. We don't need your production environment variables or secrets to do either.

Not in the current beta. We're running it as a hosted GitHub App. Self-hosting is on the roadmap if agency design partners need it for compliance reasons; ask if that's a blocker for you.

TypeScript and JavaScript first, since that's where most Shopify app and theme code lives and where the AST tooling is most mature. Other languages are a "when we have demand for it," not "if."

Reading the changelog tells you what's changing across the entire API. It doesn't tell you whether your specific code, across however many client repos you maintain, actually touches it. That mapping, at portfolio scale, is the actual work Sunset does.

It's a draft PR, so the worst case is you close it without merging, the same as any bad suggestion from a teammate. Report it and we'll use it to improve detection and generation; that feedback is exactly how the tool gets better on the cases it's currently weak on.

Shopify's deprecation schedule is public; we're not sitting on secret information, and we wouldn't claim to be. What we're building is the workflow: matching your actual code, across your whole client book, to the real change, testing the fix, and doing that reliably at agency scale. If Shopify or GitHub decide to build this themselves, that's a fair fight on execution, and we'd rather be honest about that than pretend we have a moat we don't.

See the pricing page for current tiers; Portfolio is priced per repo band, not per developer, since you're covering client infrastructure, not seats. Reach out and we'll size it against your actual repo count.

Watch, the free advisory tier, is unlimited repos and no card required. It's the honest way to see what's actually drifting in your book before you decide whether the fix tier is worth paying for.