Skip to main content

Node SDK

The Node SDK provides a comprehensive TypeScript library for easily integrating with the Mambo API. This client library simplifies development by handling authentication, request formatting, and response parsing, allowing you to focus on your application logic. Built with TypeScript and zero production dependencies, the SDK works seamlessly across Node.js, Bun, Deno, browsers, and edge runtimes.

To connect to the Mambo API, use one of the service classes provided through the client instance. See the code samples below for implementation examples.

Installation

Requirements

  • Node.js: 14.0.0 or later
  • Supported runtimes: Node.js, Bun, Deno, Edge runtimes (Cloudflare Workers, Vercel Edge)
  • Browser support: Modern browsers with Fetch API support

Dependencies

The Mambo Node SDK has zero production dependencies, making it lightweight and easy to integrate into any project. All required functionality is built directly into the SDK.

Manual Installation

The SDK is distributed as a single package containing CommonJS modules, ES Modules, and TypeScript type definitions.

Installation Steps:

  1. Download the SDK package
  2. Extract the archive to your project's node_modules/ directory

Downloads

Download the Mambo Node SDK:

Documentation

Module Systems

The SDK supports both CommonJS and ES Modules. Choose the appropriate syntax for your project:

TypeScript
ES Modules
CommonJS

Client Initialisation

To initialise the SDK, you'll need to set your credentials and, if using an on-premise installation, the API endpoint URL.

Node.js initialization with OAuth credentials:

TypeScript
JavaScript

Browser initialization (no credentials):

TypeScript
JavaScript
warning

Never include OAuth credentials in browser code. Browser applications should use a backend proxy for authentication or rely on session cookies. See the Browser vs Node.js section for details.

Runtime-Specific Usage

The SDK automatically detects and adapts to different JavaScript runtimes:

Bun
Deno
Cloudflare
Vercel

Path and Query Parameters

Use parameter objects to provide path and query parameters to endpoint methods. TypeScript provides full type safety and autocomplete for all parameters.

TypeScript
JavaScript

Request Options

Use the request options object to provide configuration on a per-request basis. This object can be used to provide idempotency keys, custom headers, or request-specific timeouts.

TypeScript
JavaScript

Working with Promises

The SDK uses async/await and native JavaScript Promises. All API methods return Promises that can be used with async/await or chained.

Async/await pattern:

TypeScript
JavaScript

Promise chaining:

TypeScript
JavaScript

Multiple async operations:

TypeScript
JavaScript

TypeScript Support

The Mambo Node SDK is built with TypeScript and includes comprehensive type definitions. No additional @types packages are needed.

Type inference:

TypeScript

Custom interfaces with SDK types:

TypeScript

Getting Started

Here's a complete example showing how to initialise the client and make a basic API call:

TypeScript
ES Modules
CommonJS

Browser vs Node.js

The SDK adapts automatically to different environments, but there are important differences in authentication and HTTP client usage.

Authentication Differences

Node.js (OAuth with credentials):

In server-side Node.js applications, you provide OAuth credentials directly to the SDK. The SDK handles token management automatically.

Node

Browser (No credentials):

Browser applications must never include OAuth credentials in client-side code. Instead, use one of these patterns:

  1. Backend Proxy: Route API calls through your backend server
  2. Session Cookies: Let your backend set session cookies that authenticate requests

For a ready-to-run backend proxy that holds the keys and forwards requests, see the Backend proxy guide.

Browser (Backend Proxy)
Browser (Custom Authenticator)
Security Warning

Never expose OAuth credentials in browser code. Anyone with access to your client-side JavaScript can extract and misuse your credentials. Always use a backend proxy or session-based authentication for browser applications.

HTTP Client Differences

The SDK automatically selects the appropriate HTTP client:

  • Node.js: Uses NodeHttpClient with native http/https modules
  • Browser/Deno/Bun/Edge: Uses FetchHttpClient with the Fetch API

You can also provide a custom HTTP client:

TypeScript

When to Use Each Environment

Use Node.js when:

  • Building server-side APIs or backend services
  • You need OAuth authentication with full credentials
  • Working with sensitive data that shouldn't be exposed to browsers
  • Building CLI tools or automation scripts

Use Browser when:

  • Building client-side web applications
  • User authentication is handled by your backend
  • You have a backend proxy for API requests
  • You're using session cookies for authentication

Troubleshooting

Common issues

Error handling

Every failure raised by the SDK rejects the promise returned by the service method, so errors are caught with a standard try/catch around await. The SDK exports the error classes below, all of which extend MamboError:

ErrorRaised when
MamboApiErrorThe API returned an error response. Extends MamboError.
AuthenticationErrorThe request was rejected with a 401 or 403. Extends MamboApiError.
IdempotencyErrorThe idempotency key was invalid, already used, or its request is still in progress. Extends MamboApiError.
OAuthErrorThe OAuth token could not be obtained. Extends MamboError.
ApiConnectionErrorThe API could not be reached. Extends MamboError.
TimeoutErrorThe request did not complete within the configured timeout. Extends MamboError.
ConfigurationErrorThe client configuration is invalid. Thrown by the MamboClient constructor.

Because JavaScript has a single catch block, you discriminate between them with instanceof, ordering the checks from most to least specific:

Node

You do not need to handle expired access tokens. When the API rejects a token, the SDK obtains a new one and replays the request transparently.

See Errors for the full list of error types returned by the API.

Connection timeouts

If you experience connection timeouts, you can increase the timeout when initialising the client. The Node SDK applies a single timeout to the whole request, expressed in milliseconds, which defaults to 30 seconds and cannot exceed 5 minutes:

Node

Retries

The SDK does not retry failed requests by default. Set maxRetries to retry connection failures, timeouts, and the responses that are safe to replay (408, 409, 429 and 5xx):

Node

Logging

Enable debug logging to troubleshoot issues:

Node