# jsforce for JavaScript access to Salesforce APIs

> jsforce is a TypeScript-based JavaScript client for several Salesforce APIs in Node.js and browser applications. Its broad API coverage comes with runtime-specific transports, browser configuration questions, and migration work between major versions.

**jsforce/jsforce** — Salesforce API Library for JavaScript applications (both on Node.js and web browser)

- Repository: https://github.com/jsforce/jsforce
- Website: https://jsforce.github.io/
- Stars: 1,473 · Forks: 552
- Language: TypeScript
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/jsforce-jsforce

## jsforce's Salesforce API Scope

jsforce addresses the problem of calling Salesforce from applications written in JavaScript. It targets both server-side applications built with Node.js and applications that execute in a web browser. The README describes the library as isomorphic and presents Salesforce API access through asynchronous JavaScript functions. That design is useful for teams that want one client package across server and browser contexts instead of separating Salesforce communication into unrelated implementations.

Its scope is wider than record querying. The README lists REST API features such as SOQL, SOSL, and describe operations, along with Apex REST, Analytics API, Bulk API, Chatter API, Metadata API, SOAP API, Streaming API, and Tooling API. The package therefore serves developers whose application may need transactional record operations, metadata deployment, analytics access, or another Salesforce interface during its lifecycle.

The package metadata identifies the published package as `jsforce`, describes it as a Salesforce API library for JavaScript, and declares `3.11.0` as its version. It also provides a CLI with an interactive console, described in the README as a REPL. The repository points developers to separate v3 and v1 API references. Those references matter because a broad API list does not by itself explain authentication details, object names, method signatures, or browser setup for each interface.

## Node.js and Browser Package Resolution

The package does not rely on one artifact for every runtime. In `package.json`, the `main` entry points to `./index`, while the `browser` mapping replaces the root and selected request-related modules with files under `browser/`. Explicit mappings cover `.`, `./index.js`, `./browser/registry`, `./browser/registry/index.js`, `./browser/request`, and `./browser/request.js`. This is the clearest visible indication that jsforce treats Node.js and browser request handling as different transport concerns.

The build configuration reflects the implementation language and output targets. TypeScript is the primary language, and the `build:node:cjs` wireit task runs `tsc -p . --pretty --incremental`. Its declared inputs are files under `src/**/*.ts` and `**/tsconfig.json`, with output under `lib/**` plus TypeScript build information. A separate `build:browser` task runs Babel over `src` with TypeScript extensions and browser settings. The top-level build depends on transpilation and bundling, while bundling depends on the browser build.

This separation makes sense for an isomorphic library, but it also creates an adoption question: runtime behavior is not necessarily identical. Browser applications depend on Salesforce's browser-facing transport and security model, while Node.js applications have different networking options. The README excerpt does not explain those transport differences in detail. It provides the API reference and identifies browser modules, but does not document proxy handling, CORS policy, browser authentication, or how outbound Salesforce calls should be routed from a browser. Engineers evaluating browser support must verify those points in the full documentation rather than assuming that the `browser` field means every Salesforce API behaves identically in both environments.

## Locating Installation Guidance and a First Salesforce Call

The repository identifies the npm package name as `jsforce` and links to the documentation site for installation and API usage. However, the README does not provide an installation command or a complete first-call example. The full v3 API reference and the Node-specific document are the available starting points identified by the repository. Adding an invented `npm install` command or authentication example would risk introducing flags, environment variables, callbacks, or Salesforce configuration that the README does not confirm.

A practical first review can still begin with the package metadata. The following excerpt shows the package identity, runtime entry point, and license recorded in `package.json`:

```json
{
  "name": "jsforce",
  "main": "./index",
  "license": "MIT",
  "version": "3.11.0"
}
```

This confirms what a developer imports as a package, where Node.js resolution begins, and which release the repository describes. It does not show how to create a connection, authenticate a user, execute SOQL, or process the response. The README directs users to the v3 API reference for method-level information and to `JSFORCE-NODE.md` for Node-specific release information. For a first real use, consult those files, select only the APIs required by the application, and confirm the authentication flow against Salesforce's current requirements before writing business logic.

The README's omission is worth stating plainly. A list of supported APIs is a compatibility claim, not an executable quick start. If an adoption decision requires a copy-and-run example, the full documentation must supply it. If the intended use depends on `loginBySoap`, there is an additional migration issue discussed later in this article.

## SOAP Login Retirement and v3 Migration Work

jsforce has a concrete compatibility deadline in its README. The SOAP `login()` API will be retired in Summer '27 at API version 65.0. The notice specifically directs users of `loginBySoap` to migrate to the OAuth 2.0 Username-Password Flow. This is not a hypothetical maintenance concern: Salesforce's retirement schedule can affect an application's authentication path even when the Salesforce records and business logic remain unchanged.

The distinction between `login()` and `loginBySoap` matters because the notice does not claim that every SOAP use is ending. It targets the SOAP login API. Applications that call SOAP for another purpose may therefore need to examine their authentication separately from their data-access method. Applications using the named `loginBySoap` method should not retain that flow unchanged through the announced retirement.

Major-version migration is another documented cost. The README provides separate guides for v1 to v3 and v2 to v3. Existing code should be checked against the applicable file rather than treated as version-independent. The repository also contains a changelog and release references, but the README does not enumerate every breaking change. The cost of upgrading therefore depends on whether the application uses legacy v1 or v2 calls, browser-specific imports, or authentication methods affected by Salesforce's schedule.

A good adoption review starts by identifying the application's current jsforce major version and authentication method. Read `MIGRATING_V1-V3.md` for a v1 codebase or `MIGRATING_V2-V3.md` for a v2 codebase. Then account for the SOAP login retirement separately, because a JavaScript client migration does not automatically resolve a Salesforce platform deprecation.

## Release Activity, Build Surface, and MIT Terms

The repository is not archived, and its last push was on 2026-10-15. Releases listed around that push include `3.11.0` on 2026-10-14, `3.10.29` on 2026-10-08, and `3.10.28` on 2026-10-02. These dates and versions show recent repository activity and repeated patch releases around the current major version. They do not establish compatibility with every Salesforce API or eliminate the need to test changes against a specific Salesforce environment.

The build surface is larger than a single TypeScript compilation. The repository includes `src/`, `core/`, `api/`, `typings/`, browser-oriented configuration, Jest configuration, Karma configuration, Webpack configuration, and entry-point files such as `index.js` and `index.d.ts`. Contributors are instructed to add test code in `test/` when implementing new features or fixing cases not covered by the library's tests. The README refers to `DEVELOPING.md` for build and test instructions.

For contributors, this layout suggests several kinds of verification: TypeScript compilation for Node.js CommonJS output, Babel processing for browser output, Webpack bundling, and test runs governed by the repository's separate configurations. The exact test commands are not included in the README, so they should not be inferred. Upgrades can require checking dependency changes, generated outputs, browser mappings, TypeScript declarations, and both runtime test configurations.

The package is licensed under the MIT License, with `LICENSE` identified in the repository. That permits use and modification under the license's conditions, including preservation of its copyright and permission notice. It does not grant access to Salesforce or remove the need to comply with Salesforce terms, credentials, data-protection obligations, or API permissions. This is a licensing boundary, not legal advice.

## When a Direct Salesforce REST Client Is a Better Fit

jsforce is a reasonable candidate when the application is written in JavaScript or TypeScript and needs access to several documented Salesforce APIs from one package. Its strongest fit is a codebase that values a shared API surface across Node.js and browser targets, or that needs the included CLI while learning Salesforce operations. The package's API list and TypeScript-oriented build make that alignment explicit.

A narrowly scoped direct REST client may be easier when the application uses only REST API features, has strict bundle-size limits, or requires authentication behavior that the browser-oriented jsforce path cannot satisfy. The README does not publish bundle sizes, so jsforce should not be described as the smaller option. A direct client can call only the endpoints the application needs and keep its runtime dependencies under the application's control. The trade-off is that developers must handle Salesforce authentication, request construction, response interpretation, and API-specific behavior themselves.

jsforce is also the wrong choice when a new application is committed to the deprecated SOAP login path and cannot make the OAuth change before the announced retirement. A direct OAuth-based client may be easier to reason about if the application does not need the rest of jsforce. Conversely, replacing jsforce with manual REST calls is not automatically simpler. jsforce already covers interfaces such as Metadata API, Bulk API, SOAP API, Streaming API, and Tooling API that would each require separate design and integration work.

## Conclusion

Engineers should adopt jsforce when one JavaScript package must expose the documented Salesforce APIs across Node.js and browser runtimes. Projects that need a narrowly scoped, dependency-light Salesforce client, or cannot use OAuth 2.0 Username-Password Flow where applicable, should verify those constraints first. Before adoption, check the v3 migration guide, inspect the required Salesforce authentication and authorization permissions, and confirm that the target runtime uses jsforce's Node.js transport or documented browser configuration.

## FAQ

### What is jsforce used for?

jsforce provides asynchronous JavaScript access to Salesforce APIs in Node.js and browser applications. Its documented coverage includes REST, Apex REST, Analytics, Bulk, Chatter, Metadata, SOAP, Streaming, and Tooling APIs.

### Does jsforce support Node.js and web browsers?

Yes. The package declares a Node.js entry through `main` and separate browser mappings under `browser`. Browser request behavior is implemented in browser-specific modules rather than assumed to be identical to the Node.js path.

### What should users of jsforce's SOAP login method do?

The README says the SOAP `login()` API will be retired in Summer '27 at API version 65.0. It directs users of `loginBySoap` to migrate to the OAuth 2.0 Username-Password Flow.

## Sources

- [jsforce/jsforce on GitHub](https://github.com/jsforce/jsforce)
- [License: MIT](https://github.com/jsforce/jsforce/blob/main/LICENSE)
- [Project website](https://jsforce.github.io/)
- [README](https://github.com/jsforce/jsforce/blob/main/README.md)
- [Releases](https://github.com/jsforce/jsforce/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jsforce-jsforce