Percher is getting started, with a limited number of registrations each day. Create an account.

Percher — Data Portability Register

Effective date: 11 October 2026

Last updated: 11 October 2026

Register version: 1.0.4

API specification version: 1.0.0 (OpenAPI 3.1.0)

This register forms part of the Percher Terms of Service. It describes the switching interfaces, data structures, formats, standards, known technical limits and infrastructure information required by Articles 26 and 28 of Regulation (EU) 2023/2854 (the Data Act).

1. Export interfaces and authentication

All paths below use https://api.percher.run as the base URL. "Bearer" means a Percher API token belonging to the Application owner. The machine-readable interface definition is the Percher OpenAPI specification.

Export	Interface and authentication	Response format
Account snapshot	`GET /account/export` — Bearer	JSON object described in Section 2
Application bundle	`POST /apps/{appRef}/export/mint` — Bearer; then one-time `GET /export/download/{token}` where the token is the download credential	gzip-compressed tar archive (`.tar.gz`) described in Section 2
Application bundle with Environment Variable values	Dashboard Application export — authenticated browser session plus fresh password confirmation; then one-time download	Same `.tar.gz` layout, with the additional secret-value files described in Section 2. Secret values are not available through Bearer-authenticated API, CLI or MCP export.
Git history availability	`GET /apps/{appRef}/export/git/check` — Bearer, owner only	JSON with `ok` and `estimatedBytes`
Git history	`GET /apps/{appRef}/export/git` — Bearer, owner only	Git bundle (`application/x-git-bundle`, `.bundle`)
PocketBase snapshot availability	`GET /apps/{appRef}/data/export/check` — Bearer, owner only	JSON status
PocketBase data	`GET /apps/{appRef}/data/export` — Bearer, owner only	gzip-compressed tar archive (`.tar.gz`) of the available `pb_data` directory

Self-service export can start immediately; assisted switching is requested as described in Terms Section 15.6. The destination provider or customer is responsible for importing and operating the Application.

2. Data structures and archive layout

2.1 Account snapshot

The JSON root contains exportedAt, user, apiTokens, alertPreferences, sharedAccess, apps, supportCases, withdrawalReceipts, dataExportUrls, perAppExports and _note. Application entries contain the Application record, deploy records, Environment Variable names and custom domains. API-token secrets, Environment Variable values and large build logs are excluded; large or per-Application data is represented by authenticated export pointers.

Application records also include iconImageRejectedCode and previewImageRejectedCode (moderation reason codes), and previewImageOrientation and previewImagePendingOrientation (approved and pending preview orientation, landscape, portrait or null). These correspond to the database fields icon_image_rejected_code, preview_image_rejected_code, preview_image_orientation and preview_image_pending_orientation. Image bytes are not included in the Account snapshot.

apps[].images[] lists uploaded icons and gallery previews, including pending images, with file, description, orientation and url. Each url is a relative public image download path (/icons/<appId>/<hash>.<ext>), not a bearer-authenticated export link.

2.2 Application bundle

The archive has one root directory named from the Application and export date:

<application>-YYYY-MM-DD/
  source/**                       # when the live source archive is available
  SOURCE-UNAVAILABLE.txt          # otherwise, the reason source is absent
  images/icon.<ext>               # available approved icon
  images/icon-pending.<ext>       # available icon awaiting review
  images/preview.<ext>            # available approved preview
  images/preview-pending.<ext>    # available preview awaiting review
  images/README.txt               # recorded images and availability notes
  README.md
  percher.toml
  env-keys.json
  domains.json
  deploy-history.json
  visitor-statistics.json
  visitor-statistics-counters.json
  build-logs.json
  runtime-logs.json
  crash-reports.json
  env-values.json                 # only after fresh password confirmation
  env-values-by-scope.json        # only after fresh password confirmation
  pocketbase/schema.json          # where automated PocketBase export is available
  pocketbase/pb_data.zip          # where automated PocketBase backup is available
  pocketbase/README.md             # otherwise, manual export instructions

The optional images/ directory contains the uploaded image files that remain available. images/README.txt identifies approved and pending files and explains missing or invalid files.

env-keys.json contains keys and a note. domains.json contains verified. deploy-history.json is an array of objects with deploy identifier, status, type, commit references, note and timestamps. env-values.json is a key/value object. env-values-by-scope.json contains rows, each with key, scope and value. pocketbase/schema.json contains the exported PocketBase collections schema.

Deployment history includes all retained live and preview deployments, ordered by identifier. Visitor-statistics files contain retained daily aggregates, ranking counters and completeness flags, not visitor hashes, salts or raw HTTP access logs. Build logs and crash reports contain the retained records. Runtime logs contain text chunks from existing app containers, excluding PocketBase sidecars; concatenate each container's chunks in array order. Status entries identify unavailable buffers, withheld output and complete reads. These JSON datasets have no export row or line-count cap and are streamed or read in pages, not as one transaction snapshot.

2.3 Git and PocketBase exports

The Git export is the complete history available in Percher's Application repository, in Git bundle format, verifiable and clonable with native Git bundle commands. The direct PocketBase export preserves the available pb_data directory tree in a .tar.gz archive for import into a compatible PocketBase installation.

3. Formats, standards and versioning

JSON follows RFC 8259.
gzip compression follows RFC 1952.
Tar archives use the conventional tar structure supported by common open-source tar tooling.
Git history follows the published Git bundle format.
PocketBase backup ZIP files use PocketBase's documented backup and restore mechanism.
HTTP interfaces are described using OpenAPI 3.1.0.

Percher updates this register when a supported structure, format or interface changes materially. No proprietary importer is required.

4. Known restrictions and technical limits

An Application bundle can include retained metadata and uploaded images without a current live deployment. Source is included only from the current live deployment when its archive is available; preview or failed deployments are not substituted. Keep your own project files.
Application export links are single-use, expire after 15 minutes and are limited to 10 export-link creations per Application per user in 24 hours.
Environment Variable values require recent password confirmation in the dashboard. Bearer-authenticated API, CLI and MCP exports exclude them by design.
Git self-service export is limited by repository and bundle size, generation time and concurrency. The current default size limit is 1 GiB and the current generation timeout is 180 seconds. The daily limit per Application is 3 exports on Free and Starter, 10 on Maker and 30 on Max.
Direct PocketBase export requires a running PocketBase Application. The daily limit per Application is 1 export on Free and Starter, 2 on Maker and 5 on Max.
PocketBase data in an Application bundle requires the Application backup endpoint to be reachable; otherwise the bundle contains manual export instructions.
Only retained data can be exported. Uploaded source directories, including build/, dist/ and out/, are preserved; symbolic and hard links are omitted for archive safety. Separately generated platform build artifacts and caches are not included.
Docker runtime logs rotate with max-size=10m and max-file=3 per existing app container, without a time-based retention limit; deleting a container removes its buffer. Known secret values of at least eight characters are masked in diagnostics; shorter or unregistered values may remain. Output is withheld when the required secret set cannot be verified. Managed platform credentials are excluded from environment-value files.
Internal control-plane credentials, security signals, abuse-detection rules, infrastructure configuration, internal identifiers and aggregated service metrics are excluded as described in Terms Section 15.6.

If a self-service limit prevents a complete export, contact support@percher.app for assisted switching.

5. Infrastructure jurisdiction

Percher is operated by Kaizensu AB in Sweden. Core hosting, storage and backups are kept in the EEA, currently in Germany and Finland, and are subject to EU law and the laws of Sweden, Germany and Finland depending on the operation and location. Providers and processing locations are listed in the Privacy Policy and Subprocessor Notice.

6. Protection against unlawful international government access

For non-personal data stored in the Union, Percher uses EEA-based core storage, controlled and logged administrative access, tenant, workload and network separation, least privilege, encryption in transit, encryption of stored secret values and off-site backups, data minimisation, limited retention, contractual provider review, and review of government requests for a valid legal basis, scope and authority. Requests are rejected or challenged where legally permitted and reasonably available. These measures do not prevent disclosure that binding EU or Member State law requires. Personal-data transfers are governed by the GDPR, the Privacy Policy and, where applicable, the DPA.

7. Contact and language

Questions about switching, formats or limitations: support@percher.app Legal and data-access questions: legal@percher.app

The English and Swedish versions are intended to have the same meaning. If they differ, the English version prevails, without limiting mandatory rights.

*Last updated: 11 October 2026*