The data-handling below is factual and grounded in the code (jpverify/). The operator's 特定商取引法に基づく表記 (legal notice: operator, address, phone, prices, payment) is published at /legal and the Terms of Service at /terms.
Last updated: 2026-09-24 · Operator: Yanagi the First Co., Ltd. (株式会社ヤナギtheファースト) · yanagithefirst11@gmail.com
JP-Verify re-serves already-public Japanese registry facts in English. This statement explains exactly what data it handles, what it deliberately does not, and how it is protected.
JP-Verify verifies a qualified-invoice (適格請求書) T-number against the daily 国税庁 (National Tax Agency) public register.
name_en/address_en are produced only for corporations, deterministically, and are labelled non-authoritative; the authoritative fields are the Japanese name/address.Source & provenance. Register data originates from the 国税庁 公表サイト public bulk/diff files, synced multiple times daily, with the source URL and data_as_of date stamped on every response. Three optional enrichment fields carry their own provenance: lei (GLEIF Legal Entity Identifier reference data, CC0 1.0 — corporate identifiers only); since September 2026, edinet (the Financial Services Agency's EDINET code list, Public Data License v1.0; the list date, attribution and processing note are returned alongside it in edinet_register); and, once enabled on or after 6 October 2026, major_shareholders (the securities-filing facts described below; their source line and processing note are returned alongside them in edinet_documents_register). The EDINET code list as published also contains individual filers (氏名/住所). Those rows and the address column are discarded at ingest and are never stored or served: the sidecar database holds six corporate columns only, and the raw file is deleted after every build, whether it succeeds or fails.
Major shareholders disclosed in securities filings (from 2026-10-06). On or after 2026-10-06 — the effective date of the Terms amendment announced on 2026-09-22 — JP-Verify starts collecting, for corporations that file a 有価証券報告書 or 半期報告書 on EDINET, the 「大株主の状況」 (major shareholders) table those issuers publish, fetched only through the official EDINET API of the Financial Services Agency; from the day the major_shareholders field is enabled (reported as major_shareholders.enabled in /health), it also returns that table, with the source line and processing note in edinet_documents_register. Purpose of this processing, stated here before the first ingest: providing verification facts about the issuer to business customers, including their provision to those customers as part of the service. We keep the names of holders positively identified as corporations or other organisations as published (and, where the name matches exactly one active entry of the corporate-number register, their Corporate Number) and every holder's rank, share count and ratio. Every other holder — which includes every individual shareholder — is returned without a name, as unresolved (or as unknown where the name cell in the filing is empty): its published name and the address column of every row are discarded in memory at ingest and are never stored, logged, signed or served, and we hold no key that could link such a row to a person or across filings. The raw filing is deleted after every build, whether it succeeds or fails. Whether a nameless row of this kind is itself personal data at JP-Verify is under counsel review; until that is settled we handle it as if it were information relating to a living individual (個人関連情報), exactly as we handle the T-number slice above: it may be used only as a fact about the issuer (Terms Art. 7(3)), never to identify or profile a person, and nameless rows (unresolved and unknown alike) are served only in aggregate form (their count and combined ratio) until the review is complete and — for customers in the business of verifying companies — until their Art. 7(3) representation is recorded against their key.
To meter usage and provide support, JP-Verify processes the minimum necessary:
| Data | Why | Retention |
|---|---|---|
| API-key label (you choose it) | identify your key for support/billing | life of the key |
| Client IP (anonymous sandbox tier) | per-IP free-tier rate limiting | 31 days, then pruned |
| Per-key/day call counts and invoices | metering, billing, bookkeeping | 7 years after the fiscal year (Japanese tax-record retention) |
Idempotency cache (request hash + the response body) — only when you send an Idempotency-Key | replay protection | 24 hours |
| Monitor watchlist numbers and your webhook URL | delivering the monitoring service you configured | life of the key |
| Business contact details of your staff (name, work email, employer) received in contracts, support or billing | contracts, support, invoicing | contract term plus statutory retention; held in our Google Workspace mailbox (United States) |
We recommend a company name (not a personal name) in a key label. The query contents you send — the T-numbers/法人番号 you look up, and any supplier name you screen — are not written to access logs by this service. The application code writes no request-content logs, and the server runs with HTTP access logging disabled (--no-access-log in the shipped systemd unit), because a default access log would capture GET query strings verbatim. The only on-disk copy of a request is the 24-hour idempotency cache above, and only for requests that carry an Idempotency-Key. Honest caveat: a query sent in a GET URL can still appear in transport logs outside this service (your own outbound proxy, a CDN edge). If that matters to you — especially for /v1/screen, where the query is a supplier *name* — use the POST variants (POST /v1/screen, POST /v1/verify), which carry the sensitive content in the request body, never in the URL. The credential database is stored with 0600 permissions; access is over TLS.
Where the data is stored, and the safeguards (安全管理措置・外的環境の把握). The account data above and the public-register mirror are stored on a server we ourselves operate in Finland (provider: Hetzner Online GmbH, Germany; processing contractually limited to the EU/EEA). Traffic reaches it through Cloudflare, Inc. (United States) edge locations, which also terminate TLS. We have reviewed the personal-data regimes of those jurisdictions (EU/GDPR, Germany, United States) and apply the following measures: credential database with 0600 file permissions; the application bound to 127.0.0.1 and exposed only through a Cloudflare Tunnel; TLS in transit; HTTP access logging disabled; sandbox IP addresses deleted after 31 days; outbound webhook targets re-validated against private-network addresses. The person responsible is the representative director.
For qualifying tiers, sign=1 returns an Ed25519-signed record you can verify offline against GET /pubkey. The signature covers the record content only; it attests provenance, not identity.
Under APPI (and, for EU-based users, the GDPR), you may request access to, correction of, or deletion of the account data we hold about you (key label, IP, usage, business contact details). Contact: yanagithefirst11@gmail.com. We verify the request from the address on file, charge no fee, and answer without undue delay. Complaints go to the same address; users in the EU/EEA/UK may also complain to their supervisory authority.
For users in the EU/EEA/UK (GDPR). The controller is Yanagi the First Co., Ltd., Tokyo. Legal bases: performance of the contract with you (Art. 6(1)(b)) and our legitimate interest in running and protecting the service (Art. 6(1)(f)). Recipients: Hetzner Online GmbH (hosting, EU) and Cloudflare, Inc. (edge network, United States, under its standard contractual clauses). Japan holds an EU adequacy decision, so data we receive from you may be processed in Japan on that basis. A data-processing agreement for customers who send us personal data to check is available on request.
This is a data-handling statement, not legal advice. Wording may be refined with counsel as paid service scales; the data-handling facts above are grounded in the code and current as of the date shown.