Security & data handling
The documents you send often contain sensitive financial data. Here is exactly what happens to them.
Sign in: password plus two-factor or a passkey
Sign in with a passkey (Face ID, Touch ID, or a security key), Google, or a password with two-factor authentication. Accounts with a password must enable an authenticator app (TOTP) before checkout, billing changes, reports and exports, sharing, API keys and MCP, bank or ledger connections, team changes, email or password changes, sender allowlist changes, and callback secrets. This also applies with a linked passkey or Google sign-in. Accounts without a password keep their existing protection rules. The free first look stays open: verify your email, sign in, upload or email in your first statement, review merchants and rules, preview My year and the locked report, view pricing, or edit your profile name. You can sign out or delete your account without TOTP; deletion keeps its existing identity check. API keys and MCP credentials are checked against their creating user on every request. If that user has a password without enabled TOTP, requests return HTTP 403 TWO_FACTOR_SETUP_REQUIRED. Organization/service keys with no creating user keep their existing behavior. Existing accountant share reports and exports also pause while their creator needs protection setup, then resume after setup. See the Two-factor authentication and Passkeys docs.
A second check before sensitive actions
Creating or revoking an API key, rotating a webhook secret, and other sensitive actions require a fresh password, two-factor code, passkey, emailed code for a passwordless account, or linked Google reauthentication first, even in an already-signed-in session. Passwordless accounts can use a single-use emailed code sent to their verified email address, valid for 10 minutes with five attempts and limited sends. Passkeys require biometric or PIN verification. Both are bound to the requesting session. Google cannot force fresh authentication; use email or a passkey when Google cannot verify freshness.
Data isolation
Every document, result, schema and webhook is scoped to an organization. Every query in the API and the app filters by organization id, at the data layer, not just in the UI.
Encrypted in transit and at rest
Every connection to Arkrel uses TLS. Documents and data are stored in Cloudflare D1 (database) and R2 (file storage), both of which encrypt everything at rest using AES-256 (R2's own encryption-at-rest page) automatically, with no configuration on our part.
Retention you control, delete any document any time, or delete your whole account
Documents and results are deleted automatically after 30 days by default. Paid plans can set retention anywhere from 1 to 90 days. You can also delete any document on demand, immediately, from the API or the dashboard. You can delete your whole account yourself, any time, from Settings: if you are the only member of your organization, everything is deleted right away, with a typed confirmation and a fresh re-check of your identity required first. Deleted data is removed from our live system right away, and from every backup copy within 30 days.
Download all your data, any time
Settings has a "Download all my data" export: a file with your original uploaded documents, extraction results, transactions with their categories, your rules, and your tax reports. It requires a fresh re-check of your identity, and the download link requires signing in.
Where extraction runs
Primary extraction runs on our own servers, using a self-hosted model, not a third-party AI vendor. If those servers are briefly unavailable, a fallback path uses Cloudflare Workers AI so a document still reaches a terminal state instead of waiting indefinitely; the same Workers AI binding also powers the transaction- categorization suggestions you can accept, edit or reject during merchant review. Cloudflare is already our hosting provider for the API, dashboard and file storage (listed in Subprocessors), and does not use data sent to Workers AI to train models. Every result states which one actually processed it.
No training on your documents
Arkrel does not use customer documents or extracted data to train models, ours or anyone else's. Documents are processed to produce your result, then retained only for the window you configure.
API keys
API keys are shown once, at creation, and stored hashed. If a key is lost, revoke it and issue a new one; the server never has the original value to show you again.
Webhook signatures
Every webhook delivery is signed with HMAC-SHA256 over the payload and a timestamp, sent in a signature header. Verify it before trusting a payload, and reject anything outside a 5-minute replay window.
URL fetching is restricted
The REST API only accepts documents you upload directly (multipart or base64) or send by email; it never fetches a URL on your behalf. The one exception is the MCP server’s extract_document tool, which can fetch a document from a URL you provide, with server-side request forgery protections: private, internal and loopback addresses are rejected, redirects are capped at 3 hops with each hop re-checked, and content over 25MB is rejected. Webhook destinations pointing at private or internal addresses are rejected the same way.
Subprocessors
A full, current list of every subprocessor we use, and what each one does, is on the Subprocessors page.
Acceptable use
The service is not for protected health information or other regulated medical records. See the Acceptable Use Policy for the full scope.
Read the full Privacy Policy. Questions about a specific requirement? Email support@arkrel.com.