> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Japan APPI (Act on Protection of Personal Information)

> Meet Japan's APPI — the data-protection regime that governs consent to marketing, special-care personal information, and Japanese data-subject rights — mapped to the sender-registration, consent ledger, DSAR pipeline, and residency surfaces Orbit already gives you.

# 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.

<Note>
  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.
</Note>

***

## 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:

```bash theme={null}
curl "https://api.orbit.devotel.io/api/v1/compliance/country-rules?channel=sms" \
  -H "Authorization: Bearer $ORBIT_API_KEY"
```

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](/compliance/sender-id-registration)); the
mechanics of the endpoint, its upstream-sync provenance, and the
`last_synced_at` freshness field are on [Country Compliance
Requirements](/compliance/country-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.

***

## Consent model and special-category handling

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.

| APPI posture question                                                                     | Orbit surface for the evidence                                                                                                                                                                                                    |
| ----------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Was the purpose of use specified and disclosed at collection?                             | [Consent API](/compliance/consent-management) — write a `purpose` string (≤ 500 chars) on each grant; re-recording refreshes proof without touching `granted_at`                                                                  |
| Does this recipient's email address require the special-category / disclosure-care class? | The `consent_type` purpose category on the same record (`marketing`, `transactional`, or a tenant-defined class) plus `lawful_basis` — set `consent` where APPI consent duties are substantive                                    |
| Is an existing-customer soft path available?                                              | APPI allows limited third-party-data-use scenarios, but PPC guidance focuses on whether you disclosed the purpose — if you rely on a soft path, the transaction reference lives in your CRM; the ledger carries the channel grant |

```bash theme={null}
curl -X POST https://api.orbit.devotel.io/api/v1/compliance/consent \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "identifier": "jordan@example.jp",
    "channels": ["email"],
    "opt_in": true,
    "consent_type": "marketing",
    "lawful_basis": "consent",
    "purpose": "Purpose-of-use disclosed at signup: promotional offers for our product line (APPI 2023 guidance duty)."
  }'
```

The [Consent Posture policies](/compliance/consent-default-policy)
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](/legal/) for the Japanese DPO contact your
representative needs. The [DSAR guide](/compliance/dsar) explains
the same pattern for GDPR Art 18 restriction — the verb set has no
Japan-specific entry; the filing discipline is yours.

| Japanese data subject right (APPI)                    | Operator `request_type`                          | Notes                                                                                                                           |
| ----------------------------------------------------- | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------- |
| Disclosure of personal information (disclosure right) | `know`                                           | Export is signed, ordered by `granted_at`, and bounded by the retention window you set                                          |
| Correction / added / elimination                      | `correct`                                        | Rectification of the contact record and ledger                                                                                  |
| Suspension of use                                     | `opt_out_sale` or `limit_sensitive_pi` annotated | CCPA/CPRA analog; annotate the APPI basis in `requester_statement`                                                              |
| Deletion (use-elimination)                            | `delete`                                         | Propagates downstream via the [subscriber erasure propagation](/guides/cdp-erasure-propagation) fold in the erasure certificate |

File a Japanese disclosure request the same way any operator-filed
request is created:

```bash theme={null}
curl -X POST https://api.orbit.devotel.io/api/v1/compliance/dsar \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "subject_email": "jordan@example.jp",
    "requester_email": "privacy@your-company.jp",
    "applicable_jurisdiction": "gdpr",
    "request_type": "know",
    "requester_statement": "APPI disclosure request (Japanese data subject; jurisdiction filed under GDPR analog per the DSAR guide)."
  }'
```

Erasure execution is the same pipeline; the
`GET /compliance/dsar/erasure-requests` surface and the signed
proof-of-deletion certificate (see [DSAR](/compliance/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](/compliance/data-processing-agreement).

***

## 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](/compliance/data-residency-overview):
the **subprocessor registry in the
[Trust Center](https://orbit.devotel.io/en/trust)** 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](/compliance/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 <code>lawful\_basis: consent</code> where the basis is subject
consent.

**Step 6 — DSAR.** Walk the [DSAR](/compliance/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.

***

## Related references

* [Consent Posture: The Unknown-Consent
  Policies](/compliance/consent-default-policy) — the two knobs this
  page configures for JP recipients.
* [Consent Management](/compliance/consent-management) — the
  ledger fields (`consent_type`, `lawful_basis`, `purpose`) APPI
  special-care handling rests on.
* [DSAR](/compliance/dsar) — the operator verb set, the
  jurisdiction-analog filing discipline, and the
  proof-of-deletion certificate.
* [Data Residency Overview](/compliance/data-residency-overview) —
  the subprocessor-registry register the APPI transfer basis cites.
* [Voice Data Residency](/compliance/voice-data-residency) — the
  one tenant-side region pin the register allows.
* [Country Compliance Requirements](/compliance/country-requirements) —
  the live `JP` sender row.
* [Sender-ID Registration](/compliance/sender-id-registration) and
  [Documents & KYC](/compliance/documents-kyc) — the registration
  and document-upload surfaces.
* [Opt-Out & Suppression Lists](/compliance/opt-out-suppression) —
  scope-`all` routing for Japanese revocations.
* [CASL (Canada)](/compliance/casl-canada-anti-spam) — the sister
  opt-in regime page; the consent-tier documentation structure
  parallels this one.
* [US CAN-SPAM](/compliance/can-spam) — the opt-out counterpart
  for non-Japanese recipients.