Volledige gegevensexport

Je kunt de gegevens van je organisatie op elk moment exporteren vanuit de beheer-UI: elke repository als git bundle, de issues, pull requests, opmerkingen, labels, mijlpalen en releases van elke repository, je pakketinventaris, je scanbevindingen en beslissingen van het pakketbeleid, je build- en release-attestaties met hun handtekeningen, de SBOM’s van je repository’s en containerimages, en het auditspoor van de afgelopen 90 dagen. Alles staat in een standaardformaat, te downloaden als één .tar.gz met een ondertekend SHA-256-manifest dat elk bestand dekt.

Deze pagina beschrijft wat er in de bundel zit, hoe je die verifieert en welke limieten gelden. De export zit in het abonnement van € 30 per gebruiker; je hebt geen Enterprise-abonnement nodig.

Wat er in de bundel zit

De indeling van de bundel, elk bestand erin en de vorm van elk record staan op één pagina: Exportschema. Kort samengevat: een git bundle per repository; de issues, pull requests, opmerkingen, labels, mijlpalen, releases en instellingen van elke repository als NDJSON; je pakketinventaris en bestandslijst; je inventaris van componenten van derden; je toegangslog van de registry; je scanbevindingen, beslissingen van het pakketbeleid en ondertekende attestaties; de SBOM’s van je repository’s en containerimages; en je auditspoor. Alles valt onder één met DSSE ondertekend SHA-256-manifest. De inhoud van pakketten komt op verzoek als tweede archief, zie §“Pakketinhoud”.

Pakketinhoud

Vink Pakketinhoud meenemen aan als je een export start (of stuur {"include_packages": true} naar de API), dan maakt de export naast de bundel een tweede archief: elk bestand van elke pakketversie die je organisatie bezit, op het moment van exporteren gelezen uit de opslag van de registry.

export-<your-org-slug>-<timestamp>.packages.tar
└── packages/
    ├── npm/<name>/<version>/<file>               — e.g. npm/@acme/lib/1.2.0/lib-1.2.0.tgz
    ├── npm/<name>/<version>/<file>.cdx.json      — the file's SBOM (CycloneDX), and .spdx.json (SPDX)
    ├── maven/<group>/<artifact>/<version>/<file>
    ├── pypi/<name>/<version>/<file>
    ├── generic/<name>/<version>/<file>          — and the same shape for every other non-container type
    └── container/<image>/                        — one OCI image layout per image
        ├── oci-layout
        ├── index.json                            — one entry per tag
        └── blobs/sha256/<digest>                 — manifests, configs and layers

• Samen met de bundel ondertekend. Het manifest.json van de bundel legt de naam, de grootte en de SHA-256 van het archief vast (packages_archive) en elk bestand daarin (objects), zodat één DSSE-handtekening beide downloads dekt. VERIFY.md in de bundel bevat de commando’s; zie ook §“De bundel verifiëren”.
• SBOM’s. Bij elk pakketbestand zit de software bill of materials die fremforge bij het uploaden ervan heeft gemaakt: <file>.cdx.json (CycloneDX) en, waar die is gemaakt, <file>.spdx.json (SPDX), naast het bestand, voor elk type behalve containers. Ze staan net als elk ander bestand in objects van het manifest. Een bestand dat de scanner niet kon verwerken, heeft er geen. Bevat een pakket zelf een bestand met precies die naam, dan blijft het bestand van het pakket behouden en wordt de SBOM weggelaten. Containerimages krijgen hier geen SBOM’s per bestand; hun SBOM’s worden beschreven in SBOM’s.
• Containers zijn OCI image layouts, die skopeo, crane, oras en podman rechtstreeks lezen. Een tag naar een andere registry pushen gaat bijvoorbeeld zo: skopeo copy oci:packages/container/<image>:<tag> docker://<registry>/<image>:<tag>.
• Gewone .tar, niet gecomprimeerd: pakketbestanden (.tgz, wheels, jars, image-lagen) zijn al gecomprimeerd.
• Downloadlink: getoond als Pakketinhoud naast de link van de bundel, en door de API teruggegeven als packages_signed_url. Net als die van de bundel 7 dagen geldig. Het archief zelf wordt na 7 dagen verwijderd; start een nieuwe export als je het opnieuw nodig hebt.
• Limiet van 50 GiB. Is de pakketinhoud van je organisatie groter dan 50 GiB, dan wordt het verzoek meteen geweigerd (export-too-large) en blijft de export zonder pakketinhoud beschikbaar. Neem contact op met support@frem.sh voor een begeleide export van grotere registry’s.

Elk bestand wordt tijdens het schrijven gecontroleerd tegen de grootte en SHA-256 uit de inventaris, en elke SBOM tegen de grootte en SHA-256 die bij het maken werden vastgelegd; een export waarvan de pakketbestanden niet overeenkomen, mislukt liever dan dat er een archief wordt geleverd dat afwijkt van zijn manifest.

Scanbevindingen, beleid, attestaties en SBOM’s

Elke export bevat ook de beveiligingsgegevens die fremforge over je organisatie bewaart, net als elk ander bestand gedekt door het ondertekende manifest:

• findings/: de bevindingen van elke scanner, elk in een eigen NDJSON-bestand (statische analyse, afhankelijkheden, licenties, containerimages, secrets, malware in uploads, afhankelijkheden en containerlagen, kwetsbaarheden en licenties van registry-pakketten, niet-vastgepinde workflow-actions), met hun afwijzingen: wie een bevinding heeft afgewezen, waarom en tot wanneer.
• policy/: je pakketbeleid, de regels voor toestaan en weigeren en de goedkeurders, het huidige oordeel voor elk pakketbestand, gate-beslissingen (inclusief die welke in schaduwmodus zouden zijn geblokkeerd), uitzonderingen met hun goedkeuringen, overrides voor malware en de organisatie-instellingen van elke scanner.
• attestations/: je build-provenance, release-attestaties en attestaties die met een SBOM zijn geüpload, elk met de DSSE-envelope en, waar die is gemaakt, de keyless Sigstore-bundel.
• sboms/: elke SBOM die fremforge bewaart voor je repository’s (sboms/repos/, CycloneDX en, waar die is gemaakt, SPDX) en je containerimages (sboms/images/), als de documenten zelf, geïndexeerd in sboms/index.ndjson. Elke regel van de index vermeldt of het document overeenkwam met de SHA-256 die bij het opslaan is vastgelegd. SBOM’s van pakketten staan hier niet: die komen naast hun bestanden in het archief met de pakketinhoud.

De bestanden en hun velden staan in Exportschema.

Wat er NIET in de bundel zit (en waarom)

• Pakketinhoud en lagen van containerimages, tenzij je erom vraagt: dan komen ze als apart archief, zie §“Pakketinhoud”.
• Inhoud van LFS-bestanden, zie §“LFS-inhoud”.
• Release-assets: releases.ndjson bevat de metadata van elke release, inclusief de download-URL van elk asset; haal de assets op via die URL’s.
• Logs en run-artefacten van Forgejo Actions: die worden niet geëxporteerd. Download de logs en artefacten van een run via de runpagina of de Actions-API zolang je ze nodig hebt.
• SBOM’s van pakketten, tenzij je om de pakketinhoud vraagt: de SBOM van elk pakketbestand in de registry reist mee naast het bestand in het archief met de pakketinhoud. SBOM’s van repository’s en containerimages zitten wel in de bundel, onder sboms/ (zie §“Scanbevindingen, beleid, attestaties en SBOM’s”).
• Facturen en facturatiegegevens: geen onderdeel van de bundel; ze staan in de beheer-UI onder Facturatie.
• Gegevens van andere tenants: het fragment uit het auditlog bevat alleen de auditgebeurtenissen van je eigen organisatie.

Een export starten

1. Beheer-UI van de organisatie → tabblad Gegevensexport.
2. Vink eventueel Pakketinhoud meenemen aan (zie §“Pakketinhoud”).
3. Klik op Nieuwe export starten.
4. De export-runner pakt de job binnen 5 minuten op. Een kleine organisatie is een paar minuten later klaar; de duur groeit met de omvang van je repository’s. Het tabblad Gegevensexport toont de status van de job en, zodra die klaar is, de downloadlink.
5. De downloadlink is 7 dagen geldig nadat de bundel klaar is, en het bundelbestand wordt 7 dagen na het aanmaken verwijderd, inclusief de kopie voor disaster recovery. Bij een legal hold blijft het bestand bewaard.

Mislukt een export, dan krijgt degene die erom vroeg een e-mail met de reden, en kun je meteen een nieuwe starten.

Rate limit

Eén export per organisatie per 24 uur. Harde limiet. Een mislukte export telt niet mee, dus je kunt het meteen opnieuw proberen. De reden: een repository van meerdere GB met git bundle inpakken en de hashes van het manifest berekenen is niet gratis, en een verkeerde klik mag niet ’s nachts honderd exports opleveren.

Heb je echt binnen 24 uur een tweede export nodig, neem dan contact op met support@frem.sh. We kunnen de limiet op verzoek opheffen.

Groottelimieten

Het archief wordt tijdens het bouwen naar de opslag gestreamd, dus de grootte wordt niet beperkt door geheugen of door een limiet op één upload. Wat een export op dit moment wel begrenst:

• Ongeveer 10 GB aan repositorybundels en metadata: de werkruimte waarin de export-runner bestanden klaarzet voordat ze worden gearchiveerd.
• Eén uur voor de hele export.
• 50 GiB aan pakketinhoud, als je daarom vraagt; wordt al bij het verzoek geweigerd, zie §“Pakketinhoud”.

Een organisatie boven een van deze limieten krijgt een foutmelding in plaats van een onvolledige bundel. Neem contact op met support@frem.sh, dan voeren we in plaats daarvan een begeleide export uit (meestal een directe synchronisatie naar je eigen bucket).

Bij de meeste organisaties is de inhoud van de repository’s veruit het grootste deel; metadata en auditgegevens zijn in vergelijking klein.

De bundel verifiëren

Controleren of elk bestand ongeschonden is aangekomen, kost één run van sha256sum. Vereiste: jq (het SHA-256-hulpprogramma zit in elk modern besturingssysteem: sha256sum op Linux, shasum -a 256 op macOS).

Pak het archief uit en voer dan in de uitgepakte map uit:

# Linux
sha256sum --check <(jq -r '.files[] | "\(.sha256)  \(.path)"' manifest.json)

# macOS
shasum -a 256 -c <(jq -r '.files[] | "\(.sha256)  \(.path)"' manifest.json)

Meldt elke regel OK, dan komt elk bestand in de bundel overeen met de SHA-256-hash die fremforge heeft vastgelegd. Een afgebroken of beschadigde download pakt niet goed uit of zakt voor deze controle.

Wat dit wel en niet afvangt

De SHA-256-controle vangt manipulatie na de export af (een beschadigde download, wijziging door een MITM van een niet-ondertekende mirror) en koppelt de bundel aan het manifest dat fremforge heeft gemaakt. Om te bewijzen dat het manifest zelf door fremforge is gemaakt (en niet door een derde die je bundel door de zijne heeft vervangen), voer je de verificatie van het ondertekende manifest uit de volgende sectie uit: die bindt de bytes van het manifest cryptografisch aan de gepubliceerde Ed25519-builder-sleutel van fremforge.

Het ondertekende manifest verifiëren

De bundel bevat in manifest.json.intoto.jsonl een met DSSE ondertekend in-toto-Statement over manifest.json. De handtekening wordt gezet met de Ed25519-sleutel van de SLSA-builder van fremforge, dezelfde sleutel die de SLSA-build-provenance ondertekent van artefacten die op de gehoste runner worden gebouwd, en wordt geverifieerd tegen de publieke trust root op https://www.frem.sh/.well-known/slsa-trust-root.json. De actieve sleutel is fremforge-slsa-builder-v2, in gebruik sinds de sleutelwissel van 2026-09-12; de commando’s hieronder selecteren die. VERIFY.md in je bundel bevat dezelfde commando’s, ingevuld met de sleutel die die bundel heeft ondertekend.

Gebruik de sleutel die de envelope noemt. De keyid in manifest.json.intoto.jsonl (jq -r '.signatures[0].keyid' manifest.json.intoto.jsonl) is de sleutel die hem heeft ondertekend. Een bundel die vóór 2026-09-12 is geëxporteerd, is ondertekend met fremforge-slsa-builder-v1, die in de trust root blijft om oude handtekeningen te verifiëren (er wordt niets meer mee ondertekend); kies voor zo’n bundel fremforge-slsa-builder-v1 in stap 1. Een actuele bundel verifieert niet met v1: stap 2 geeft dan DSSE signature verification FAILED.

Je verifieert met curl, jq, openssl en python3, die alle standaard in distributies zitten. Geen fremforge-CLI. Geen afhankelijkheid van Sigstore Fulcio, Rekor of een TUF-CDN.

1. Haal de publieke trust root op en haal de publieke sleutel eruit

curl -sSfL https://www.frem.sh/.well-known/slsa-trust-root.json -o trust-root.json
jq -r '.trusted_keys[] | select(.kid=="fremforge-slsa-builder-v2") | .pem' \
  trust-root.json > builder.pub

2. Verifieer de handtekening van de DSSE-envelope

python3 - <<'PY'
import base64, json, hashlib, subprocess, sys, pathlib

env = json.loads(pathlib.Path("manifest.json.intoto.jsonl").read_text().strip())
payload_type = env["payloadType"]
payload_b64  = env["payload"]
payload      = base64.b64decode(payload_b64)

# Reconstruct the DSSE pre-authentication encoding.
pae = (
    b"DSSEv1 "
    + str(len(payload_type)).encode() + b" "
    + payload_type.encode() + b" "
    + str(len(payload)).encode() + b" "
    + payload
)
pathlib.Path("pae.bin").write_bytes(pae)

sig_b64 = env["signatures"][0]["sig"]
pathlib.Path("sig.bin").write_bytes(base64.b64decode(sig_b64))

# Ed25519 verify with openssl: pkeyutl -verify needs the SAME bytes
# the signer hashed. EdDSA is "pure" — no pre-hash — so feed the
# raw PAE buffer.
r = subprocess.run(
    ["openssl", "pkeyutl", "-verify", "-pubin",
     "-inkey", "builder.pub",
     "-rawin", "-in", "pae.bin",
     "-sigfile", "sig.bin"],
    capture_output=True, text=True,
)
if r.returncode != 0 or "Signature Verified Successfully" not in r.stdout:
    print("DSSE signature verification FAILED:", r.stdout, r.stderr, file=sys.stderr)
    sys.exit(1)
print("DSSE signature: OK")

# Cross-check the signed manifestSha256 matches the on-disk manifest.json.
stmt = json.loads(payload)
claimed = stmt["predicate"]["manifestSha256"]
actual  = hashlib.sha256(pathlib.Path("manifest.json").read_bytes()).hexdigest()
if claimed != actual:
    print(f"manifestSha256 mismatch: signed={claimed} actual={actual}", file=sys.stderr)
    sys.exit(1)
print(f"manifestSha256: OK ({actual})")

# Sanity-check the predicate type.
if stmt["predicateType"] != "https://fremforge.eu/spec/export-bundle/v1":
    print(f"unexpected predicateType: {stmt['predicateType']}", file=sys.stderr)
    sys.exit(1)
print("predicateType: OK")
PY

3. Verifieer de SHA-256 van elk bestand tegen het (nu vertrouwde) manifest

# Linux:
sha256sum --check <(jq -r '.files[] | "\(.sha256)  \(.path)"' manifest.json)

# macOS:
shasum -a 256 -c <(jq -r '.files[] | "\(.sha256)  \(.path)"' manifest.json)

Slagen alle drie de stappen, dan is de bundel van begin tot eind manipulatiebestendig: elk bestand komt overeen met de SHA-256 die fremforge heeft vastgelegd, het manifest komt overeen met wat fremforge heeft ondertekend, en de handtekening is gezet met de gepubliceerde builder-sleutel.

4. Pakketinhoud (alleen als je erom hebt gevraagd)

Download de .packages.tar naar dezelfde map en controleer dan het archief en elk bestand daarin tegen hetzelfde ondertekende manifest:

echo "$(jq -r '.packages_archive.sha256' manifest.json)  $(jq -r '.packages_archive.name' manifest.json)" | sha256sum --check
tar -xf "$(jq -r '.packages_archive.name' manifest.json)"
sha256sum --check <(jq -r '.objects[] | "\(.sha256)  \(.path)"' manifest.json)

Wat de handtekening bewijst

• De bytes van de bundel die je hebt ontvangen, zijn byte voor byte gelijk aan wat fremforge op het moment van exporteren heeft gemaakt.
• Het manifest is gemaakt met de builder-sleutel van fremforge, niet door een derde.
• Het ondertekende predicaat (https://fremforge.eu/spec/export-bundle/v1) vermeldt de slug van de organisatie, de ID van het exportverzoek, het aantal bestanden en het totale aantal bytes; een bundel van een andere tenant ervoor in de plaats zetten zou dus niet verifiëren.

Wat ze niet bewijst

• Tijdigheid: de ondertekende exportedAt is een bewering van fremforge; voor tijdstempels waarvoor een derde kan instaan, vergelijk je het auditlogfragment in de bundel met de publieke, in WORM verankerde auditketen.
• Intrekking van sleutels: de JSON van de trust root is de bron van waarheid; trekt fremforge de builder-sleutel later in, dan verifiëren oude handtekeningen niet meer zodra de sleutel uit trusted_keys verdwijnt. Haal de trust root opnieuw op als je lang na de export verifieert.

Een repository opnieuw klonen uit een bundel

Elke bundles/<repo>.bundle is een standaard git bundle. Zo herstel je hem:

git clone bundles/<repo>.bundle <repo>
cd <repo>
git remote remove origin                  # bundle URL is local
git remote add origin <new-fremforge-or-elsewhere-url>
git push -u --mirror origin

--mirror behoudt alle branches, tags en refs. De bundel reconstrueert de volledige geschiedenis van de repository, met identieke SHA’s, zonder dat er naar een nieuwe remote een force-push nodig is.

LFS-inhoud

De inhoud van LFS-bestanden zit niet in de bundel. De git bundle bevat de pointer van elk LFS-bestand (de oid en size), dus de geschiedenis is volledig; de inhoud zelf blijft op de LFS-server van fremforge. Vele gigabytes aan binaire bijlagen in elke export opnemen zou die voor iedereen enorm laten groeien.

metadata/<repo>/lfs-manifest.ndjson is de LFS-inventaris per repository: één regel per LFS-object waarnaar een branch, tag of pull request in de repository verwijst.

De inventaris wordt opgebouwd uit de geschiedenis van de repository, dus objecten die naar de LFS-server zijn geüpload maar waarnaar geen branch, tag of pull request verwijst, staan er niet in. Een repository zonder LFS krijgt een leeg bestand. Verwijst de geschiedenis van de repository naar LFS-objecten maar kan de LFS-server van fremforge niet worden bevraagd, dan mislukt de export liever dan dat er een onvolledige inventaris wordt geleverd.

Zo download je de LFS-inhoud, nadat je de repository uit de bundel opnieuw hebt gekloond:

git lfs install
git lfs fetch --all

Dit haalt de inhoud op van de LFS-server van fremforge zolang je nog betalende klant bent (LFS-bandbreedte is inbegrepen). Na opzegging bewaren we je gegevens 90 dagen; in die periode werkt ophalen via LFS gewoon.

Voor een enterprise-export waarin de LFS-bytes zijn opgenomen, neem je contact op met support. We bepalen dan de omvang van de bundel en voeren de export mogelijk uit als een synchronisatie van OBS naar OBS in plaats van als downloadbaar archief.

Overstappen naar een andere aanbieder (EU Data Act)

Deze sectie is de informatieverstrekking die art. 26 van de EU Data Act (Verordening (EU) 2023/2854) vereist. De contractuele voorwaarden daarachter staan in Gebruiksvoorwaarden §16.6.

Je kunt op elk moment overstappen naar een andere aanbieder, alles overzetten naar je eigen infrastructuur of alles laten wissen, met of zonder opzegging.

Formaten. Alles in de bundel staat in een open standaardformaat (git bundle, JSONL, in-toto DSSE, JSON), beschreven op de pagina Exportschema. Geen eigen formaat van fremforge, en je hebt geen tooling van fremforge nodig om er iets van te lezen.

Importeren in een self-hosted Forgejo. fremforge draait een aangepaste Forgejo-build, maar de patches veranderen het datamodel van Forgejo niet, dus een export laat zich rechtstreeks importeren in een standaard self-hosted Forgejo-instantie. Kloon elke repository opnieuw uit de bundel (§“Een repository opnieuw klonen uit een bundel”) en push met --mirror naar de nieuwe host. Issues en pull requests verhuizen via de met de GitHub-API compatibele endpoints die hieronder worden genoemd.

Liever wissen. Wil je dat de gegevens verdwijnen in plaats van verhuizen, zeg dat dan in hetzelfde verzoek. We wissen alle exporteerbare gegevens en digitale bezittingen volgens verwerkersovereenkomst §9 en bevestigen dat schriftelijk.

Hulp hoort erbij. Volgens Gebruiksvoorwaarden §16.6(h) helpen we te goeder trouw bij de overstap, inclusief het beantwoorden van technische vragen van de aanbieder waarnaar je overstapt. Vraag het gewoon.

Opzeggen en de export

Als je je fremforge-abonnement opzegt:

• Blijft je laatste exportvenster van 7 dagen geldig. De ondertekende URL blijft werken.
• Kun je tijdens de bewaartermijn van 90 dagen met alleen-lezentoegang na opzegging op elk moment een nieuwe export starten. Zelfde flow, zelfde UI, zelfde bundel.
• Wordt een export die laat in de termijn van 90 dagen in de wachtrij komt, zelfs op +89 dagen en 23 uur, nog uitgevoerd: fremforge stelt het fysiek verwijderen van je Forgejo-organisatie tot 7 dagen na de grens van 90 dagen uit zolang er een export in de wachtrij staat of loopt. Is de export klaar, dan gaat het verwijderen door bij de volgende geplande opruimronde.
• Worden de gegevens na 90 dagen (plus de extra exporttermijn hierboven) gewist volgens verwerkersovereenkomst §9; daarmee eindigt ook de mogelijkheid om te exporteren.

Zeg je op juist omdat je een laatste export wilt, maak dan eerst de export, verifieer die lokaal en zeg daarna op. De termijn is ruim, maar eerst verifiëren en dan verwijderen is de zorgvuldige volgorde.

Maar één repository?

De volledige export geldt voor de hele organisatie: elke repository met de issues, pull requests en releases, de pakketinventaris en het auditfragment, in één ondertekende bundel. Heb je maar één repository nodig, dan zijn dit de eenvoudigere wegen:

• git clone --mirror: de volledige Git-geschiedenis, branches en tags als bare repository die je offline kunt klonen. fremforge stelt poort 22 niet publiek open; gebruik het endpoint voor SSH via poort 443 (ssh.frem.sh:443) of de HTTPS-variant:

  # SSH over port 443 (single endpoint for all orgs; uses your registered SSH key):
  git clone --mirror ssh://git@ssh.frem.sh:443/<org>/<repo>.git
  
  # OR HTTPS clone with a PAT (`ffp_…`) from Settings → API tokens:
  git clone --mirror "https://x-access-token:${FREMFORGE_PAT}@frem.sh/<org>/<repo>.git"
  
  cd <repo>.git
  git lfs fetch --all   # if the repo uses LFS

  De fingerprints van de hostsleutels van ssh.frem.sh staan op www.frem.sh/ssh-fingerprints; controleer ze bij de eerste verbinding. Het resultaat is een map die klaar is voor git bundle; pak hem in met tar -czf voor één draagbaar bestand.

• Repository downloaden als zip of tarball: frem.sh/<org>/<repo>/archive/<branch>.zip of .tar.gz voor een momentopname van één ref. Geen geschiedenis, geen LFS, alleen de werkboom op die branch.

• Issues en PR’s per repository als JSON: via de API, GET /api/v1/repos/<org>/<repo>/issues?state=all&type=issues en ?type=pulls. De migratiegidsen tonen hoe de aanroep eruitziet; het antwoord is JSON die compatibel is met de GitHub-API.

De ondertekende export van de hele organisatie is het juiste middel als je alles wilt (elke repository, de metadata, het auditlogfragment, het ondertekende manifest); de wegen per repository hierboven zijn geschikt voor het alledaagse geval “ik moet deze ene repository naar iemand sturen”.

Programmatische API

Dezelfde export is bereikbaar via de REST API:

# Start a new export
curl -X POST \
  -H "Authorization: Bearer <your-PAT>" \
  https://frem.sh/_app/api/v1/orgs/<your-org>/exports

# ... or with package contents (separate archive, 50 GiB limit)
curl -X POST \
  -H "Authorization: Bearer <your-PAT>" -H "Content-Type: application/json" \
  -d '{"include_packages": true}' \
  https://frem.sh/_app/api/v1/orgs/<your-org>/exports

# Poll for status
curl -H "Authorization: Bearer <your-PAT>" \
  https://frem.sh/_app/api/v1/orgs/<your-org>/exports/<job-id>

# When status=ready, follow the signed_url field
# (and packages_signed_url, if you asked for package contents)

OpenAPI-specificatie: docs.frem.sh/reference/api/.

Privacygaranties

De export is in beide richtingen controleerbaar:

• Wie heeft geëxporteerd: elk exportverzoek wordt vastgelegd in je eigen auditlog (data-export.requested vanuit de beheer-UI, data-export.queue.api vanuit de API), met de gebruiker of het token dat het verzoek deed. Handelingen die de support van fremverk op je organisatie uitvoert, worden in hetzelfde log als zodanig gemarkeerd.
• Wiens gegevens: het auditlogfragment wordt geselecteerd op de tenant-ID van je organisatie, dus het bevat alleen de auditgebeurtenissen van je eigen organisatie.
• Zorgvuldig omgaan met ondertekende URL’s: de download-URL is een vooraf ondertekende link met alleen leestoegang tot jouw ene archief, 7 dagen geldig. Daarna werkt de URL niet meer en verdwijnt de export van het tabblad Gegevensexport.

Zie ook

• Prijzen: inbegrepen in het abonnement van € 30 per gebruiker; geen apart abonnement.
• Verwerkersovereenkomst §9: de toezegging over het teruggeven van gegevens waaraan dit voldoet.
• Trust: hoe dit past in het bredere verhaal over soevereiniteit en controle.