Skip to main content
Two official SDKs wrap the REST API: yungle-client for JavaScript and TypeScript, and yungle for Python. Use one when you would rather call methods than build requests, and want resumable uploads and safe retries handled for you. Both are open source in heindewilde/yungle-clients. Their READMEs: JavaScript and Python.

Install

Create a client

Create an API key with the scopes you need and keep it in YUNGLE_API_KEY.
The Python client holds an HTTP connection pool. Use it as a context manager (with Yungle() as yungle:) or call close() when you are done.

Operations

Every endpoint is a method. The table lists the ones you reach for most; the API reference documents each request and response. files entries are { name, size, path?, type? }, with size the exact byte count and path the folder the file belongs in, such as Ceremony/Raw. Both SDKs also accept imports, files Yungle fetches from a URL itself; wait for them with waitForImports or wait_for_imports.

Uploads

Creating a transfer, or registering collection files, returns a tusEndpoint and one target per file. Each SDK uploads one file to one target over tus, resumably:
Both upload helpers:
  • Continue from the offset the server last committed, after a dropped connection or a server error.
  • Renew the two-hour upload token for as long as the upload runs.
  • Return the upload URL. Pass it back (uploadUrl in JavaScript, upload_url= in Python) to resume the same upload from another process. Never start a second upload for the same file: it starts over.
In Node, fs.openAsBlob(path) streams from disk without loading the file into memory. Upload large files explains the protocol underneath.

Errors and retries

A failed request throws YungleApiError in JavaScript and raises YungleError in Python. Branch on code; the message is for people and may change.
Both clients retry for you, up to maxRetries / max_retries times:
  • 429 is always retried, because a throttled request did nothing.
  • 5xx is retried for GET, DELETE and POST. Every POST carries an Idempotency-Key that stays the same across its retries, so a retried create returns the first result instead of making a second one. PATCH is not retried.
  • A dropped connection is retried by the Python client, under the same rules as a 5xx. The JavaScript client throws the fetch error instead.
  • The wait honors Retry-After when the server sends one, and otherwise backs off exponentially with jitter.
Set the retry count to 0 to handle retries yourself.

Verify webhooks

Each SDK exports a helper that checks the Yungle-Signature header against the raw request body, and rejects a timestamp more than five minutes old.
The JavaScript helper is async because it uses WebCrypto, which lets it run on edge runtimes. Change the window with { toleranceSeconds } or tolerance_seconds=. See Webhooks for the full receiver.

What the SDKs cannot reach

Your vault and end-to-end encrypted transfers are encrypted with keys Yungle never holds, so the SDKs cannot read their contents. The JavaScript SDK can create an end-to-end encrypted transfer when you encrypt the files yourself with the yungle-e2e package. See Unsupported.

Versions

Both are versioned 0.x. Pin the version you tested against, and read the changes before you upgrade. The API itself is versioned in its path (/api/v1); see the changelog.

Next steps

Send from Python

A full script with the Python SDK.

Send a transfer

The transfer flow, with curl, JavaScript, Python and the CLI.

Webhooks

Events, signatures, retries and a worked example.

Errors

Every error code and what to do about it.