Guides
Learn More about Newline

SDK Reference

This page describes the structure and conventions of the Newline TypeScript SDK Reference, which contains the authoritative documentation for all SDK resources, methods, configuration options, and error types.

The SDK Reference is generated directly from the Newline API specification and should be treated as the source of truth for SDK behavior.

Purpose of the SDK Reference

The SDK Reference exists to answer detailed, implementation‑specific questions such as:

  • What methods are available for a given resource
  • What parameters a method accepts
  • What response shapes to expect
  • What errors may be returned
  • Which operations support retries
  • How advanced configuration options behave

Conceptual usage, lifecycle guidance, and workflows are covered in other guides. This reference focuses strictly on what the SDK exposes and how it behaves.

Relationship to Other SDK Documentation

The SDK documentation is organized by intent:

  • SDK Overview — What the SDK is and when to use it
  • Quick Start — Install, authenticate, and make a first API call
  • Authentication & Environment Setup — Credential and environment configuration
  • Using the SDK — Common patterns and workflows
  • SDK Reference — Complete, authoritative method documentation (this section)

Use the SDK Reference alongside higher‑level guides when implementing features.

Resource Organization

The SDK is organized into resource groups, each representing a domain within the Newline platform.

Examples include:

  • auth
  • transactions
  • transfers
  • returns
  • customers
  • accounts
  • products
  • reporting
  • sandbox

Each resource group exposes methods that map directly to Newline API endpoints.

Example pattern:

newlineSDK.transactions.list(...)
newlineSDK.transfers.initiate(...)
newlineSDK.customers.getById(...)

Resource grouping mirrors the API and does not introduce new behavior.

Method Conventions

SDK methods follow consistent conventions:

  • Method names match API actions (e.g., list, get, create, update)
  • Parameters are passed as a single object
  • Required and optional fields are enforced through TypeScript types
  • Responses reflect the API response schema directly

There is no SDK‑specific data transformation unless documented.

Standalone Functions

In addition to client‑based usage, all SDK operations are available as standalone functions.

Standalone functions:

  • Provide the same behavior as client methods
  • Are ideal for browser or serverless environments
  • Support tree‑shaking to reduce bundle size

Standalone function documentation is included in the SDK Reference and mirrors client methods exactly.

Authentication Behavior

All SDK requests use program‑level authentication.

Important notes:

  • Authentication behavior is identical to direct API usage
  • Credentials are provided during SDK initialization
  • Token generation and request signing are handled internally
  • No per‑request authentication configuration is required

Authentication details and configuration options are documented in the reference where applicable.

Error Classes and Handling

All SDK errors inherit from a common base error type and preserve API error semantics.

The SDK Reference documents:

  • All possible error classes
  • Which methods may throw specific errors
  • HTTP status codes and error payload structures

Errors returned by the SDK should be handled according to the same rules as API errors.

Retry Support

Some SDK operations support retries.

The SDK Reference indicates:

  • Which methods support retries
  • Default retry behavior
  • Configuration options for overriding retry strategies

Retry behavior is aligned with API guarantees and does not broaden idempotency beyond what is explicitly supported.

Environment and Server Configuration

The SDK supports multiple environments and server configurations.

The reference documents:

  • Supported server names
  • Server URL overrides
  • How server selection affects requests

Environment selection does not change SDK semantics, only the target API endpoint.

Reporting and Lifecycle Notes

While the SDK exposes reporting‑related endpoints, lifecycle semantics such as settlement, posting, and reconciliation are not altered by SDK usage.

Important reminders:

  • CSV reports remain authoritative for reconciliation
  • Posted dates may populate later than settlement
  • Lifecycle interpretation should follow reporting documentation

The SDK Reference documents access methods, not lifecycle guarantees.

Generated Nature of the SDK Reference

The SDK Reference is generated automatically from the API specification.

As a result:

  • Method lists are exhaustive
  • Parameter definitions are exact
  • Manual edits are not retained
  • Documentation updates track API evolution

When discrepancies arise, the API specification and generated reference prevail.

How to Use the SDK Reference Effectively

Use the SDK Reference to:

  • Look up exact method signatures
  • Validate required parameters
  • Understand error conditions
  • Confirm retry and configuration behavior
  • Explore available resources

Use other SDK guides for:

  • Learning workflows
  • Understanding lifecycle timing
  • Designing reconciliation processes

Updated 8 days ago