Security
How the platform is built, what protects your keys and data, what we have not yet done, and how to report a vulnerability.
This page describes what is actually implemented. Where something is not done, it says so — a security page that only lists strengths is a security page a procurement team cannot use.
Access to the platform
API keys are stored as hashes, never in plain text. A key is shown once at creation. If it is lost we cannot recover it, and we will not; you issue a new one and revoke the old.
Keys carry an environment: wi_test_ keys are metered but never billed, so an integration can be exercised fully before it costs anything.
Every request carries a request identifier, and administrative actions are written to an append-only audit log.
Traffic leaving the platform
Requests are checked before they are made. URLs are validated against server-side request forgery gates: private address ranges, link-local addresses, and redirects that would cross into them are refused rather than followed. A path disallowed by robots.txt returns an error instead of being fetched.
Requests toward one domain are paced regardless of how fast you send them. There is no setting that disables this, and support cannot disable it for you.
Data at rest and in transit
All connections to the API use TLS. Stored artifacts — rendered pages, screenshots — are retrieved through short-lived signed URLs, not through public object storage.
Observations and account records are held in one location, Tokyo, Japan. There is no region selection. Tell us if you have a residency requirement before you sign up, so we can say plainly whether we can meet it.
Retention and deletion
Retention periods are configured per workspace and enforced by a scheduled deletion job rather than left to manual housekeeping. On termination we delete workspace data within 30 days, sooner on request, and confirm when it is done.
How the platform is built
The code is covered by automated checks that run before anything ships: type checking, unit tests, and a mutation guard that deletes each load-bearing mechanism in turn and fails if the tests still pass — because a mechanism no test defends is a mechanism nobody is protecting.
Data that leaves the system passes a further set of executable checks. Reports do not generate when one fails.
Third-party certification
FID Ltd. holds ISO/IEC 27001:2022 (JIS Q 27001:2023) certification for its information security management system.
| Registration | IR0268 — verifiable in the ISMS-AC register |
| First granted | 6 August 2025 (valid to 5 August 2028) |
| Certification body | IMJ Assessment and Registration Center (accreditation ISR029) |
| Scope | Planning, development, operation and maintenance of cloud-based web marketing tools and mail-order systems; consulting, advertising operations and call-centre services for mail-order businesses |
The scope is quoted verbatim. Certification is granted to an organisation for a stated scope, and "the company holds it" does not tell you whether this product falls inside that scope. Judge from the wording above.
FID Ltd. has also held the PrivacyMark since October 2015 (granted by JIPDEC).
What we have not done
- No SOC 2 report. It has not been undertaken. We would rather say that than imply otherwise.
- No third-party penetration test has been published. If your procurement requires one, tell us and we will discuss scope and timing.
- No published uptime history yet. Availability targets exist only on plans whose order form states them.
Reporting a vulnerability
Write to us with enough detail to reproduce the issue. We will acknowledge within three business days, keep you informed while we work, and credit you if you would like to be credited.
We will not take legal action against good-faith research that stays within your own account, avoids other customers' data, does not degrade the service for others, and gives us reasonable time to fix the issue before disclosure.
Last updated