What the API cannot do

Read this before you design an integration around the API. Some of these limits follow from how encryption works and will never change. Others are decisions, and a few are gaps that may close later.

​

Never possible

​

The vault

The vault is encrypted with a key derived in your browser from a passphrase that never reaches Yungle. No server-side path leads to its contents: not the API, not previews, not Yungle staff. So the API treats the vault as if it did not exist. Asking for it by id returns 404 not_found, the same as any resource that is not yours. An API that could read the vault would mean the vault did not work.

​

Reading end-to-end encrypted transfers

An end-to-end encrypted transfer is encrypted on the sender’s device, and its key travels only in the # part of the link. Yungle holds ciphertext it cannot open. As a result:

• Yungle cannot email such a transfer, protect it with a password, or store a title for it. Finalizing one with recipients, password, title or a plain message returns 400 invalid_request.
• Download links for your own end-to-end encrypted transfer return 409 e2ee_unsupported. Open the full link, # part included, in a browser.
• Yungle cannot fetch files from URLs into one, because it would see them.

You can still create one through the API with "e2ee": true, if your client encrypts each file before uploading it. The yungle-e2e package does that encryption.

​

Left out on purpose

​

Billing, plans, members and keys

There are no endpoints, and no scopes, for subscriptions, payment methods, invoices, credit, workspace members, API keys or deleting an account. These act on a person’s own account rather than on the workspace’s files, and a machine credential stays out of them. Use the dashboard.

​

Who can reach a collection

You cannot change a collection’s visibility, password or readable custom link through the API. Each one decides who can see a client’s files, and the dashboard shows the consequence next to the control. Creating collections and filling them is automation; deciding who gets in is not.

​

Use from a browser

The API is server-to-server. It sends no CORS headers, and the upload endpoint accepts browser uploads only from yungle.co. Never ship an API key to a browser or a mobile app: a key acts as your whole workspace, and anything in front-end code is public.

​

Not available today

• Moving or renaming. Files and folders in a collection cannot be renamed or moved, and folders cannot be deleted. You can delete files.
• Changing a sent transfer’s files. Once a transfer is sent, you cannot add or remove files. Send a new transfer instead.
• Deleting an upload request. You can pause or close one; closing is final.
• Bulk contact import. Create contacts one request at a time.
• Search and filtering. Lists come back whole or paged. Filter in your own code.
• Paging the shorter lists. Only transfers, collection files and webhook events are paged. Contacts, collections, folders, guests and upload requests come back complete. Download receipts return the 200 most recent events. See Pagination.
• A sandbox or test mode. Every key works on your real workspace. Keys start with yk_live_ so a test mode can be told apart later.

​

Next steps