Best Google Apps Script Libraries (2026 Edition)

A library, in Apps Script terms, is a script project that other scripts can import by its Script ID. The mechanism is simple — paste a Script ID in your project's appsscript.json, give it an identifier, and call its functions. The ecosystem built on top of this is the most underrated part of Apps Script: dozens of high-quality, drop-in libraries that solve the things you'd otherwise re-invent on every project.

This is the 2026 working set — the libraries the community reaches for first, in roughly the order you'll need them.

You can browse the full Libraries directory for the complete list. Below is the opinionated short version.

1. OAuth2 (the Google library)

If your Apps Script project needs to authenticate to a non-Google API — Slack, GitHub, Stripe, Notion, anything — you need OAuth2. Google publishes an official OAuth2 library maintained by the Workspace team, and it's so foundational that almost every other library in this list assumes you have it.

What it gives you:

• Pre-built service objects for ~30 common providers (GitHub, Slack, Salesforce, etc.)
• Token storage and refresh handled automatically (via PropertiesService)
• Standard authorization flow with callback handling
• Both 3-legged (user-authorized) and 2-legged (service account) flows

Install it, then a Slack integration is about ten lines of code instead of a hundred. There's an OAuth1 sibling library for the rare legacy provider that still needs it.

2. A batch operations library for Sheets

The single biggest performance trap in Apps Script is calling SpreadsheetApp.getRange() and setValue() in a loop. Each call is a synchronous round-trip to Google's servers; 1000 cells written one at a time will take 30+ seconds and likely hit the execution-time limit.

The right pattern is to read once, mutate in memory, write once. The libraries in our directory for batch sheet operations wrap this pattern with a friendlier API — you write code that looks like cell-by-cell updates and they coalesce into a single setValues() call. For any nontrivial Sheets script, the speedup is 10-100x.

3. A structured logging library

console.log works, but it produces a flat stream of strings that's painful to query. The serious Apps Script projects we see all use a structured logger that:

• Emits JSON-structured records
• Includes severity (INFO, WARN, ERROR)
• Captures execution context (function name, user, project)
• Optionally ships to Cloud Logging where you can query with Logs Explorer

If your add-on has more than ~50 users, set this up before you ship. The first time you need to debug "why did this fail for one customer yesterday at 3pm," you'll thank yourself.

4. A rate-limited HTTP client

UrlFetchApp.fetch() has no built-in rate limiting, retries, or backoff. Most production-grade Apps Script code wraps it in something that does. The community libraries in this space typically give you:

• Exponential backoff on 429 / 5xx responses
• A token-bucket rate limiter you configure per-host
• Optional response caching via CacheService
• Async-ish batching with UrlFetchApp.fetchAll

This is the difference between an integration that survives one Slack outage and one that doesn't.

5. Date / time utilities

Apps Script ships with the standard JavaScript Date object, which is — let's be polite — quirky. Several libraries fill the gap with a Moment-or-date-fns-style API: parsing, formatting, timezone handling, business-day calculations, and recurring-event math.

For triggers that fire on schedules, a date library is basically mandatory. The DST edge cases alone justify the import.

6. Workspace API wrappers (for the parts Apps Script gets wrong)

Some Workspace APIs are exposed in Apps Script through services that are awkward to use directly — Drive's bulk operations, Calendar's recurrence rules, Gmail's batch send. The community has produced thin wrapper libraries that expose ergonomic APIs over the messier corners. If you're spending more than 20 lines wrangling a single Workspace API call, there's probably a library for it.

7. Testing libraries

Apps Script has no built-in testing. The community has filled this with a few approaches:

• In-Apps-Script assertion libraries — a describe/it/expect API that runs inside the Apps Script runtime. Useful for testing code that actually touches Workspace APIs.
• Node-based testing with shims — extract pure logic into its own file, test with Jest/Vitest in Node, then clasp push only. This is the right approach for anything that doesn't need the Workspace context.

The best projects use both: shim-based tests for the 80% of logic that's just business rules, in-runtime tests for the 20% that has to call SpreadsheetApp.

How to install a library

The mechanism hasn't changed in years:

1. Open your Apps Script project at script.google.com
2. Click the + next to "Libraries" in the editor's left sidebar
3. Paste the Script ID
4. Pick a version (always pin to a specific version — never use HEAD in production)
5. Pick an identifier (this is the name you'll call: OAuth2.createService(...))

Or, with clasp + a manifest, add it directly to appsscript.json:

{
  "dependencies": {
    "libraries": [
      {
        "userSymbol": "OAuth2",
        "libraryId": "1B7FSrk5Zi6L1rSxxTDgDEUsPzlukDsi4KGuTMorsTQHhGBzBkMun4iDF",
        "version": "43"
      }
    ]
  }
}

A word on library performance

Libraries in Apps Script are slower than inlined code by a small but non-zero amount — each library call crosses a process boundary. For most projects this is invisible. For tight loops calling library functions thousands of times, it can be the difference between a 30-second job and a 6-minute timeout. Profile before optimizing, but know that "inline the library function" is a valid escape hatch.

What to install on day one

For a fresh Apps Script project, a reasonable starting set is:

1. OAuth2 (always, even if you don't think you'll need it)
2. A structured logger
3. A batch sheet-operations library (if you touch Sheets)
4. A date library (if you do anything time-driven)

Everything else, add when you need it. The full Libraries directory has the complete list; the Boilerplates section has starter projects that pre-wire several of these together.

If you build a library worth sharing, submit it. The Apps Script ecosystem is small enough that good utilities still get discovered.