Palladin Export and Switching Specification
Polish version: Eksport danych i zmiana dostawcy Palladin — the Polish version is legally binding.
1. Starting the process
A User may create an export in account settings after re-authentication. An Organization Administrator may create an Organization export within their permissions. A request to switch provider, port data to the Customer’s own infrastructure or erase without migration may be submitted in the Service or to patryk.roguszewski@palladin.io.
The backend export is made available as a ZIP archive through a signed link valid for 24 hours. Plaintext Entry contents are decrypted and added solely on the unlocked device. Palladin does not receive them in plaintext.
2. Time limits and fees
The maximum notice period preceding switching is two months. The standard transitional period is up to 30 calendar days. If technically unfeasible, within 14 working days we give reasons and an alternative period no longer than seven months. The Customer may extend the transitional period once for an appropriate period of its choice.
After the transitional period, data remain retrievable for at least 30 days. They are then erased from production systems and from backups no later than within 90 days, unless law requires continued retention. Palladin charges no switching fees.
3. Archive contents
The canonical format is UTF-8 JSON conforming to the schema version identified in manifest.json. Entries and audit logs are also available as CSV. Dates use ISO 8601 UTC and relations use stable identifiers.
| File or directory | Contents |
|---|---|
manifest.json | schema version, creation time, scope, record counts, omissions and SHA-256 file digests |
account.json | profile, language, preferences, account dates, onboarding and material consent history |
organizations.json | Organizations, settings, memberships, invitations, roles and permissions |
vaults.json | Vaults, folders and structure, memberships, metadata and timestamps |
entries.json, entries.csv | Entries, custom fields, relations and metadata; ciphertext and optional plaintext following local decryption |
assets/ | attachments, user-supplied icons and other digital assets, where added by the User |
crypto.json | format versions, public keys, key envelopes and KDF parameters needed to read the encrypted export |
agents.json | Agent identifiers, names, public keys or non-secret hints, status, configuration and assignments |
accesses.json | requests and reasons, decisions, scope, methods, TTL, usage limits, status, creation, revocation and Access-use history |
audit-log.json, audit-log.csv | event, time, actor, target, result and non-secret metadata available within Plan retention |
billing.json | Plan, entitlement, purchase channel, period, status and billing identifiers held by Palladin |
notifications.json | notification preferences and non-secret device-registration metadata |
Invoices and sales documents are obtained from the seller for the purchase channel: Paddle, the Apple App Store or Google Play.
4. Excluded data
The archive excludes the Master Password, private keys, API secrets, full API keys, password hashes or verifiers, raw session, refresh or push tokens, payment-card data, internal anti-fraud rules, risk scores, infrastructure secrets and data whose disclosure would infringe another person’s rights. Internal data are excluded only where this does not impede effective switching.
5. Large exports, integrity and support
Large exports are generated asynchronously. manifest.json lists all files, sizes, record counts, SHA-256 digests and any partial failures. An incomplete export is clearly marked and may be retried. The schema is versioned; a backwards-incompatible change is published before it takes effect.
Migration and format support: patryk.roguszewski@palladin.io, tel. +48 517 777 441.
6. Infrastructure and third-country governmental access
The primary infrastructure runs in AWS eu-west-1 in Ireland and is subject to Irish and European Union jurisdiction. Data are encrypted in transit and at rest, Entry contents additionally remain client-side encrypted, administrative access is restricted and audited, and non-EEA transfers are governed by the mechanisms described in the Privacy Policy and “Data Recipients and Processors”.