This website is currently read-only. For enquiries, please email us. [email protected]
Privacy Policy
Last updated:
At Hato API, we respect your privacy and are committed to protecting the information you entrust to us. This Privacy Policy describes how we collect, use, store, and safeguard your account information, request definitions, and execution artifacts.
Hato API is an Australian registered business name. ABN: 47 618 691 045. In these policies, Hato API, we, us and our refer to the operator identified by this ABN.
1. Information we collect
Account & Profile
We collect your email address, display name, language and timezone preferences, plan tier, and account verification status. Passwords are cryptographically hashed and never stored in plain text.
Request Configurations
We store Letterflow request components, delivery policy settings, Letterflow definitions, and schedules. Regional request content may include target URLs, headers, bodies, protocol credentials, and uploaded or generated SFTP private keys.
Execution Artifacts & Letterbox
Executions produce status, timing, and usage metadata, together with regional request and response artifacts. Letterflow artifacts include frozen definitions, expressions, intermediate outputs, and detailed errors. Temporary Value tests do not save their evaluation results.
Integration & Security Logs
We store Integration API key names, prefixes, secret hashes, permissions, and lifecycle timestamps. We process IP addresses and email identifiers for rate limiting using hashed Redis keys. Production access logs record client IP addresses, timestamps, request identifiers, methods, broad route categories, status, sizes, and timing. Retained logs exclude raw request paths, query strings, authorization headers, cookies, and request or response bodies.
For abuse prevention, we store blocked IP addresses and networks, destination blacklist rules, ban expiry, and related staff actions. Proxy counters are held in memory, while native regional traffic counters temporarily store source IP addresses in the regional database.
Account recovery and email
We store verification and recovery challenges, email delivery inputs and status, provider message identifiers, bounce and complaint suppressions, and audit records of staff recovery actions.
Contact submissions and browser storage
Contact submissions contain your reply email, inquiry type, and message. Essential cookies support sessions, request security, and language selection. Your browser also stores your theme preference locally.
Directory values can contain text, secrets, JSON/XML documents, shared headers, credentials and private keys. Their contents are encrypted in the selected Spoke; the Hub keeps names, types, sizes, dependency paths and revision references. Authorized references can transfer needed content to a Coordinator or Letter execution region. Directory read permission on a paid integration key explicitly includes access to secrets.
2. How we use your information
-
Delivering API Letterflows.
We use your Letter and Delivery Policy definitions to dispatch HTTP, FTP, and SFTP requests on your behalf and deliver responses back to your Letterbox.
-
Service notifications & verification.
We use email for signup verification, password recovery, verified email changes, security notices, and replies to contact inquiries. Authorized staff can perform account recovery; those actions are audited.
Contact submissions are stored in the Hub for authorized staff to review. Replies are sent manually through the operator's email provider, which processes the reply address and correspondence. The contact form does not send acknowledgement or notification emails. We use email addresses and request IP addresses to limit abusive submissions.
-
Enforcing fair use and security limits.
We monitor request volumes and schedule frequencies against plan quotas. We use access, diagnostic, authentication, and administrative event records to prevent abuse, investigate faults and security incidents, and audit privileged actions. These records can include IP addresses and internal account, job, task, and request identifiers.
3. Regional data storage and isolation
Our hosting arrangement places Hub account data and its database backups in Japan. Regional Spokes process execution content in their selected countries. Authorized operators may administer these systems from Australia. Email providers, payment providers, browser asset providers and destination services have separate processing locations; selecting a Spoke does not keep all personal information in that country.
Logs are stored on the relevant Hub or Spoke deployment host and may be accessed from Australia by authorized operators. Log archives are excluded from routine backups. Database backups have a separate retention lifecycle and may contain older audit copies until those backups expire; restored audit histories are pruned before public access resumes.
Regional execution
The Hub stores account data, display names and descriptions, plans, schedules, routing information, and operational metadata. Saved request URLs, credentials, headers, bodies, detailed errors, Letterflow definitions, and evaluated results are stored and processed in selected regional Spokes. Your browser uploads and reads this content directly using signed regional URLs.
A Letterflow's selected Coordinator processes its definition and execution context. Multi-region Letterflows transfer content between that Coordinator and the selected Letter regions. Changing a Letter's region can also transfer its saved inputs. Target services receive the request content needed for the deliveries you configure; account and email data are not covered by the regional execution-content boundary.
Multi-tenant isolation
Letterbox entries and artifacts are scoped to the owning account. Browser and integration artifact access uses short-lived, signed URLs restricted to the owner, artifact, and permitted operation. Anyone holding a valid bearer URL can use it until it expires, so keep these URLs confidential.
4. Data retention and pruning
Saved Directory values remain while saved, subject to deletion and protected revision references. Waiting deliveries have no automatic expiry: their frozen input revisions remain protected until the delivery completes or is canceled. Editing a variable does not replace a revision already captured by a waiting or active delivery.
Unattached uploads and generated private keys become eligible for cleanup after one hour. Temporary uploads have separate byte and file-count limits. Inputs attached to saved definitions or admitted active runs remain protected; saved-content and Letterbox retention allowances still apply.
| Data type | Retention period | Management control |
|---|---|---|
| Account & Letter configurations | Kept while the account or saved configuration exists; see account deletion below | Edit or delete from Dashboard / Settings |
| Unpinned execution content | Default maximum age: Tinkerer 14 days; Aspiring 60 days; Coder 180 days | Expires automatically; may be removed earlier by FIFO, clearing, or deletion |
| Pinned execution content | Exempt from automatic expiry and normal FIFO removal while pinned | Counts toward storage capacity; can be explicitly deleted |
| Integration API keys | Key records remain until account deletion; revocation does not erase the record | Revoke in Settings; keys may expire, be disabled by plan limits, or be revoked after password changes |
| Contact inquiries and internal notes | 60 days after closure; open inquiries remain until closed | Deleted by daily cleanup; external mailbox copies have their own retention |
| Email deliveries and provider event receipts | Terminal delivery records and event receipts are cleaned up after 30 days; challenges are cleaned up seven days after expiry | Pending deliveries are processed separately; external mailbox copies have their own retention |
| Routine access and diagnostic logs | Normally retained for up to 30 days, with automatic expiry; storage limits may remove logs earlier | Restricted to authorized operators for troubleshooting, security, and auditing |
| Security event logs and administrative audit histories | Security event logs and account-recovery, limit-change, and network-protection audit histories normally expire after 90 days. Active protection rules and email suppressions are retained separately. | Restricted to authorized operators for troubleshooting, security, and auditing |
Execution retention starts when a result is stored and covers headers, URLs, errors, expressions, intermediate results, and frozen definitions as well as bodies. Expired content cannot receive new access grants, even before physical cleanup runs. Minimal operational metadata may remain in the Hub. Saved request inputs have a separate lifecycle from execution history.
Clearing the Letterbox preserves pinned entries. Unpinning restores the deadline measured from the original result storage time under the applicable plan, so old content may expire immediately. Pinning cannot restore expired content. Storage limits or a downgrade storage freeze can prevent new results from being retained, even when execution succeeds. Account-specific policy exceptions may change the default limits.
Individual Letter, Letterflow, and Letterbox deletion requests queue cleanup of associated regional artifacts. Shared saved inputs and active execution inputs remain protected. Account deletion removes Hub account records and access and durably queues an owner-wide purge in every configured or referenced region. Regional purges block further access and writes, stop active work, and remove regional files and execution queue records. Unavailable regions are retried; erasure is asynchronous. Access, security, and audit records may remain after account deletion until their retention periods expire. Email suppressions and necessary protection state follow separate lifecycles.
Minimal owner identifiers remain in deletion fences to reject stale grants.
5. Third-party disclosures & security
Paddle is the authorized reseller and merchant of record for paid purchases; Hato provides the service. Paddle handles checkout, payment details, taxes and billing records under its own privacy policy. Hato receives the identifiers and subscription information needed to manage your access, rather than card details.
Account deletion removes Hato's account-linked billing mirror after cancellation is confirmed. A minimal webhook inbox retains provider event and object identifiers, timestamps, and processing status to prevent duplicate processing; it does not retain full payment payloads or card details. Paddle may retain financial records under its own policies and applicable requirements.
We do not sell, rent, or trade your personal data or API payload information to advertisers or data brokers. Hosting and infrastructure providers process data to operate the Hub and regional Spokes. Configured target services receive dispatched request data, and multi-region Letterflows transfer execution content as described above.
Production email uses Amazon Simple Email Service (SES). Recipient addresses and message content, including verification links and security notices, are processed by that provider. Delivery, bounce, and complaint events are processed through Amazon SNS. Email processing has its own configured region and does not follow your Letter's selected region. Development uses a dummy email backend by default.
Development installations can be configured to send application email through SendPulse. When enabled, SendPulse processes recipient addresses and message content, including verification and recovery links and security notices. This email processing is separate from the region selected for API execution.
Letterflow Email components send the destination address, subject, message body, and optional Reply-To to the configured email provider. Templates and evaluated message content are stored in the selected Coordinator region. Email provider processing uses its configured location. The Hub keeps quota and delivery metadata and keyed recipient fingerprints for suppression; deleting Letterbox history does not reset usage. Provider feedback headers and message content are discarded without storage. HTML messages are sanitized, and open/click tracking is disabled.
Paddle.js loads on the payment page. Other pages load fonts from Google Fonts; the Letterflow editor also loads assets from UNPKG and cdnjs. These requests disclose connection information such as your IP address and browser request details to those providers. Local browser storage keeps your theme and display-currency preferences. The Hub fetches exchange rates, so your browser does not contact the exchange-rate provider directly.
Letterflow cookie sessions are separate from website login cookies. Temporary session artifacts are cleaned up after the run through regional lifecycle processing. Cookie and Set-Cookie values recorded in retained request or response headers follow the history retention and pinning rules, so not every cookie value is erased when a flow ends.
6. Contact and policy updates
You can request access to or correction of your personal information, ask about deletion, or raise a privacy complaint through our public contact form. We may verify your identity before disclosing or changing account data. We assess requests under applicable law, explain relevant retention limits, and respond using the reply address you provide. Applicable rights to complain to a privacy regulator are not restricted by this policy.
We may update this Privacy Policy from time to time to reflect service enhancements or legal requirements. Updated policies will be posted on this page with an updated revision date.