Skip to main content

​
Japan APPI (Act on Protection of Personal Information)

Japan’s Act on the Protection of Personal Information (APPI), enforced by the Personal Information Protection Commission (PPC), is the regime Japanese recipients and their organisations audit you against. For marketing sends it is largely a purpose-and-disclosure regime: you must specify the purpose of use before you collect personal information, obtain consent before using it beyond that purpose, and treat a defined class of categories — e-mail addresses in the 2023-revision guidance, and the classic “special care required personal information” (health, race, creed, and the rest of the PPC’s enumerated list) — with extra care, including consent where the row demands it. Cross-border transfer (APPI Joint Order class) requires either the subject’s consent, an adequate-level country or framework, or system raises, and you must also record what is transferred: the APPI is not a “send first, ask later” law for Japanese data subjects. APPI places the duty on the business operator, not the platform. Orbit never mandates your Japan posture — it gives you the sender registration atlas, the tenant-controlled consent ledger, the DSAR pipeline, and the published residency register. This page maps each APPI obligation to the Orbit surface you already have so your reviewers can close the gaps deliberately before you send to Japanese recipients.
This page is documentation, not legal advice — an engineering map of product surfaces, not a legal opinion. APPI carries PPC enforcement powers (including business-improvement orders and criminal penalties for false reporting); have counsel review your purpose-of-use disclosure, your special-care handling, and your cross-border transfer basis. Orbit supplies the record-keeping surfaces — the legal posture is yours.

​
The JP row: sender registration under APPI’s shadow

Japan’s sender rules sit where telecom regulation and APPI meet: the carrier side (NTT Docomo, KDDI, Softbank, Rakuten) dictates how a message may be addressed and what survives delivery, while APPI governs whether you may address the person at all. Read the live JP row before you provision a Japanese sender — the country-rules endpoint is the ops-curated register that records the current registration posture per channel:
The endpoint filters by channel and an optional region (the multi-row register key); pass the full set or scope to the region bucket Japan rows live in and pick the row where country_code is JP in the response — the endpoint returns one row per (country, channel) so the JP SMS row and the JP voice row are separate entries. Read the row’s registration field (none / recommended / required) together with sender_types and content_restrictions: in Japan the carrier co-regulation of SMS sender identity (URL stripping, registration of alphanumeric senders) is an operator-side obligation that rides on top of your APPI posture — clearing the APPI consent check does not by itself make a Japanese send deliverable. When the row says recommended or required, submit the Sender ID through POST /compliance/sender-id-registrations and track approval over the same surface (full flow); the mechanics of the endpoint, its upstream-sync provenance, and the last_synced_at freshness field are on Country Compliance Requirements. One Japan-specific carrier behaviour your senders must plan for: the major Japanese carriers strip URLs from A2P SMS non-deterministically, and Orbit surfaces a compose-time soft warning for it rather than blocking — expect the warning on JP-destination bodies that contain a URL, and treat it as a deliverability risk flag, not a consent signal. That warning is the platform’s only JP send-time intervention; every other APPI-relevant decision below is a tenant-owned control.
APPI’s consent questions arrive at two tiers. The first is purpose-of-use: you must have specified (and, for direct-marketing uses under the PPC’s guidance, obtained the data subject’s association against further use unless the purpose is re-specified) before you collect. The second is the class of special care required personal information — health information, race, creed, political opinion, and the other categories APPI enumerates — which requires consent at collection or disclosure, and the 2023-revision guidance that encourages operators to treat e-mail addresses as the channel identifier demanding disclosure scrutiny. Both tiers map onto Orbit’s tenant-controlled consent ledger; the ledger does not mandate a Japan gate — it records the posture YOU set.
The Consent Posture policies list APPI alongside GDPR/LGPD in the opt-in class your default sends should assume for Japanese recipients; keep the org unknown_marketing_policy: refuse default and the consent_default_policy: deny_on_missing posture so a contact with no ledger row receives no marketing. Both knobs are tenant-owned — the strict-tenant rule applies: no platform gate beyond the federal voice window, every other control is yours.

​
DSAR and erasure for Japanese data subjects

APPI grants Japanese data subjects rights to disclosure (revelation), correction/added/elimination, and suspension/deletion of their personal information. The Orbit DSAR pipeline files each right under the operator verb set it already supports — the Japanese operator picks the jurisdiction and verb; the platform tracks the statutory clock per jurisdiction. The applicable_jurisdiction enum does not carry a japan / appi value by design — your operator files the Japanese request under the closest coded jurisdiction (GDPR for access/deletion, CCPA/CPRA for the analog classes) and records the actual regime in requester_statement; browse the contacts page of the published Legal index for the Japanese DPO contact your representative needs. The DSAR guide explains the same pattern for GDPR Art 18 restriction — the verb set has no Japan-specific entry; the filing discipline is yours. File a Japanese disclosure request the same way any operator-filed request is created:
Erasure execution is the same pipeline; the GET /compliance/dsar/erasure-requests surface and the signed proof-of-deletion certificate (see DSAR) give the Japanese subject — or a PPC reviewer — the receipt. For the deletion flow to be defensible in Japan the exposure order (reason for disclosure, corrections process, deletion with propagation) must appear in your privacy notice; that notice is tenant-owned content, filed alongside the DPA register.

​
Cross-border transfer rules (SCC-class basis)

APPI’s cross-border condition (Joint Order ~2021 rule 24) is the PPC’s answer to the adequacy question: foreign transfer of personal information requires either the subject’s consent, an adequacy-level jurisdiction (the PPC’s published list — the EU is recognised, the UK/Switzerland and several others are not yet), or a framework the business has raised (contract clauses, intra-group rules). Which of the three a Japanese subject’s data moves under is a determination you run per launch, not a default the platform assumes. The surface the decision cites is the published data-residency register: the subprocessor registry in the Trust Center names where Devotel and its named subprocessors process platform data, per entry, with data-residency notes — for messaging channels (email / SMS / WhatsApp / RCS) that registry entry is the residency answer a Japanese subject’s data relies on, and for voice the Voice data residency pin (eu / us / auto) adds the channel’s resident region on top. Record the APPI transfer basis against the register entry, next to the channels it covers — not against a per-workspace toggle, since messaging residency on Orbit is a platform-side commitment, not a tenant switch. When your Japanese subjects’ data must rely on consent-basis transfer, the Consent ledger’s lawful_basis: consent row is the record the PPC reviewer asks to see.

​
Worked configuration

A Japanese consumer program — email with SMS — reads as this sequence. Each step is a tenant-owned decision Orbit enforces; none is a platform mandate. Step 1 — posture. Keep unknown_marketing_policy: refuse and consent_default_policy: deny_on_missing for JP recipients. Step 2 — sender row. Read the JP row from GET /compliance/country-rules?channel=sms; if registration says recommended or required, file the Sender ID through /compliance/sender-id-registrations and track approval. Step 3 — consent. At acquisition, record the grant with a disclosed purpose and lawful_basis: consent; raise special-category care for email addresses against the consent_type purpose category if PPC guidance requires it. Step 4 — URL warning policy. Decide how your senders handle the JP carrier URL-strip soft warning (shorten on tenant side, accept partial delivery, or change channel). Step 5 — residency / transfer basis. Anchor the APPI transfer basis to the subprocessor-registry entry in the Trust Center, and raise lawful_basis: consent where the basis is subject consent. Step 6 — DSAR. Walk the DSAR guide and file Japanese subjects under the closest coded jurisdiction, recording the APPI regime in requester_statement. The result is a defensible Japan posture: sender identity is registered where the JP row says it should be, Japanese recipients backed by recorded consent, the transfer basis anchored to the published register, and every decision lands in the audit trail.