GKit Roadmap: What We're Building in 2026

Where we are

SheetsAPI shipped its public beta this week. The core is working — you can point it at any Google Sheet, get a REST API with filtering, sorting, and pagination, and build something real on top of it. A few people already have. That's the proof of concept we needed.

The rest of 2026 is about making the foundation trustworthy and shipping the second product. Here's an honest look at what we're planning — these are intentions, not promises. Priorities shift; timelines slip. We'll update this post when they do.

SheetsAPI: graduating from beta

The beta label means "it works but we're still finding edges." Before we call SheetsAPI stable, we want to close a handful of things:

Rate limiting dashboard. Right now rate limits are enforced but not visible to you. We plan to add a simple usage view to the GKit dashboard — requests per day, current limit, where you are in the quota. Nothing elaborate; just enough to make the limits predictable.

More output formats. JSON, CSV, TSV, and XML are live today. We're looking at NDJSON (newline-delimited JSON) for streaming use cases, and a proper application/vnd.api+json response shape for teams that care about JSON:API compliance. These are lower priority than stability work.

Cleaner error messages. The error responses right now are functional but terse. We want errors to say what went wrong specifically — wrong sheet name, missing column, quota exceeded — so you don't have to guess.

Drive Cleaner: the second product

The next tool in the GKit suite is Drive Cleaner. The idea: scan a Google Drive for duplicate files and large files you've forgotten about, show you a clear breakdown, and let you remove or organize them in bulk.

Google Drive accumulates clutter fast — duplicate exports, old versions of decks, large video files from three projects ago. There's no native "show me what's taking up space" view that's actually useful.

Drive Cleaner will be a web tool with OAuth sign-in, no permanent access to your files, and a clear breakdown by size and duplicate group. We're in early design; this is a second-half-of-2026 target.

GKit marketplace: verified listings

The GKit marketplace currently accepts tool submissions by email. That works at small scale, but it doesn't scale and it's not a good experience for developers who want to list their tools.

The plan is a self-serve submission form with a lightweight review step — we check that the tool is real, the description is accurate, and the pricing is honest, then approve it. A "verified by GKit" badge for tools that meet a higher bar (documentation, uptime, support channel) will come after the form is stable.

Developer experience: npm package and webhooks

Two developer-facing improvements we're actively thinking about:

Official TypeScript client. Right now you fetch the SheetsAPI endpoints directly. We're working on a typed npm package — @gkit/sheets — that wraps the REST API with type inference from your sheet's header row. It's a nicer interface for TypeScript projects and makes it easier to swap to a different backend later without rewriting every call site.

Webhooks via Apps Script bridge. Google Sheets does not support native webhooks. Our plan is an optional Apps Script you install in your spreadsheet that fires a POST to your endpoint when rows change. It's an imperfect substitute for real push events, but it covers the most common case: "tell my app when someone edits the sheet." We'll document the limitations clearly.

Platform: API key scoping and usage analytics

Two platform-level features that come after SheetsAPI is stable:

API key scoping. Today a key is either active or revoked. We want read-only keys — useful for public-facing apps where you want to guarantee no writes happen — and eventually per-sheet keys that limit access to a specific spreadsheet.

Usage analytics. A per-key breakdown of requests, errors, and response times, visible in the GKit dashboard. Useful for debugging and for deciding when you've grown out of the free tier.

What we're not building (yet)

To keep scope honest: we're not building a SQL query layer on top of Sheets, a managed Postgres service, or a visual no-code app builder. Those are interesting products, but they're not GKit. The focus for 2026 is making the tools we have reliable and shipping Drive Cleaner.

If you have strong opinions about any of this, open a GitHub issue or email us. Roadmaps are more useful when the people who'd actually use the features weigh in.