A collection per client

A transfer is a one-off send that expires. When a client should have one lasting place for everything you deliver, give them a collection — and when you onboard clients from your own system, create it from there. Collections are part of the paid plans.

1. Create the collection

The response carries url, the collection’s secret link. It is 128 bits and checked on every request; treat it like a password you are allowed to hand to the client.

curl -X POST https://yungle.co/api/v1/collections \
  -H "Authorization: Bearer $YUNGLE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"title":"De Vries BV","description":"Everything we deliver, in one place."}'

# → { "collection": { "id": "01J…", "url": "https://yungle.co/c/…", … } }

2. Upload with the folders intact

Send a path with each file and the folder tree is built for you, in one go. Doing it twice lands in the folders that already exist rather than making copies.

# Uploads the folder, building the same tree inside the collection.
yungle push ./Deliverables --collection 01J…

3. Give the client access

Two ways, and they combine:

Share the link — send collection.url yourself, from your own system’s email.
Invite them as a guest — POST /collections/{id}/guests with up to 25 emails per call. Guests can view, download, favourite and comment on that one collection and nothing else.

curl -X POST https://yungle.co/api/v1/collections/01J…/guests \
  -H "Authorization: Bearer $YUNGLE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"emails":["anna@devries.example"]}'

A collection created through the API is never reachable at a readable address on your own domain until you switch that on in the dashboard — readable means guessable. See Collections.