ADMINDeployed website service#
The YAADMIN website now implements the email-code activation protocol expected by the current Core account coordinator. This page describes the website API, not a claim that an installed Windows build has been configured or tested.
Live configuration and endpoint map · Public signing-key descriptor
The exact issuer is https://yaadmin.io/, including the trailing slash. Provision the public Ed25519 key through a trusted deployment channel. Never send SMTP credentials or the private signing key to Core.
HTTPS operations#
All operations below use POST JSON under https://yaadmin.io/wp-json/yaadmin/v1/account/. Every body includes schema_version: 1 and the stable UUID installation_id.
| Client operation | Endpoint suffix | Additional request fields |
|---|---|---|
| email_request | email-request | email, activation_session_id, delivery_channel=email |
| email_verify | email-verify | challenge_id, activation_session_id, code |
| activate / refresh | refresh | Existing installation bearer authentication |
| unlink | unlink | account_id and existing installation bearer authentication |
Use the Authorization Bearer header or X-YAADMIN-Installation-Token, never a token in the URL. Requests to an already active installation require its current credential and retain account ownership. Account changes require authorized unlink first.
Request and confirm the code#
The email request returns HTTP 202 with challenge_id, issued_at, expires_at, resend_after_seconds and delivery_channel. Codes expire after exactly 600 seconds, resend cooldown is 60 seconds, and five incorrect attempts lock a challenge. The API never returns the code. It checks email syntax and mail-capable DNS; DNS alone cannot prove that a particular mailbox exists. Entering the emailed code proves access to the address.
Verification accepts a six-digit string, preserving leading zeros. HTTP 200 returns account_assertion, entitlements, installation_credential and registration_subscription. Each signed envelope contains payload (the exact signed JSON string), signature (base64 Ed25519) and key_id.
The assertion binds issuer, installation, activation session, challenge, method=email, verified account, timestamps, the entitlement payload hash and credential hash. Validate every binding before applying entitlements or storing the credential through the existing protected vault.
Signed entitlements, refresh and unlink#
The signed snapshot contains schema_version=1, installation_id, increasing revision, edition, status, issued_at, valid_from, valid_until, perpetual_use, license_id, refresh_after, offline_until, grants and support. It represents existing rights; registration does not issue paid rights. Existing fixed-term paid plans are not converted into perpetual licenses by this protocol.
Refresh returns the signed snapshot envelope directly. Unlink returns a signed installation_unlink assertion and a signed Free snapshot with empty grants, revokes that installation token, and retains account purchases. Repeated/concurrent verification cannot issue a second credential from the same challenge.
YAADMIN_REG registration list#
After successful code verification, the address is automatically added to the AcyMailing YAADMIN_REG technical registration/service list. Repeated activations do not create duplicate contacts. Existing global/list opt-outs and existing confirmation state are preserved. This list does not create marketing consent or launch a campaign.
The response reports subscribed, subscribed_confirmation_preserved, opt_out_preserved or pending. Temporary synchronization failures are queued for bounded retries. List membership and website account registration are separate records.
Errors#
Errors use a JSON error field containing a fixed code. Common values are activation_email_invalid, activation_mail_failed, activation_code_invalid, activation_code_expired, activation_code_used, activation_attempts_exhausted, activation_request_throttled, activation_session_invalid, installation_credential_invalid and account_relink_requires_authorized_unlink. Secret-bearing responses are private/no-store.
Verification and local integration status#
Server fixtures, legacy compatibility, public HTTPS concurrency and the original Core signature/activation methods were checked. SMTP accepted a real test message; inbox receipt was not inspected. Windows, DPAPI persistence and the packaged application were not exercised in that historical email-service audit. Newer source adds website linking and signed-file activation without internet. Follow current activation instructions; this older contract does not imply that other activation methods are unavailable.