---
name: phylex-account-api
description: Safely automate one Phylex account, including customer-scoped Phylex Shield controls.
---

# Phylex Account API and Shield

Use this skill only for server-side automation owned by the account that issued the key.

## Required rules

1. Read `https://billing.phylex.net/docs/api/account`, `https://billing.phylex.net/docs/api/shield`, and `https://billing.phylex.net/docs/api/security` before writing code.
2. Use `https://billing.phylex.net/openapi/account-api-v1.yaml` as the endpoint contract and `https://billing.phylex.net/sdk/phylex-account.ts` as the reference SDK.
3. Read the key from `PHYLEX_API_KEY`. Never print, log, embed, commit, or return it.
4. Keep the key on a trusted backend and send it only as `Authorization: Bearer`.
5. Use public `PHX-SVC-*` and logical Shield rule references. Never use or request numeric service IDs, router UUIDs, interfaces, provider rule IDs, or control-plane credentials.
6. Treat every `404` as opaque. Do not probe for another account's services or rules.
7. For every mutation, persist one `Idempotency-Key` per logical operation and retry with the same key and identical payload.
8. Never accept a destination IP from application input for Shield. Atlas derives the exact /32 or /128 from the owned service.
9. Basic panel controls allow three versioned safe presets per IP and 25 rules per account, but have no Account API access. The Account API Shield façade requires Advanced, which allows 30 rules per IP and 300 per account, including up to 10 PPS/BPS rules per IP.
10. A rollback affects only the selected customer-managed rule or its profile bundle. Do not represent it as changing emergency or network-wide policy.

## Shield workflow

- Confirm that the account has Advanced, then read the service Shield overview and current entitlement.
- Check `mutations_blocked`, readiness, quota, and whether the same preset is already desired.
- Apply a preset/profile or create an Advanced custom rule with a durable idempotency key.
- Poll the sanitized logical rule state until `active` or a terminal failure; do not guess success from HTTP 202.
- Show `last_error_code` without exposing upstream response bodies.
- Roll back using the logical rule ID, then confirm `rolled_back` or `canceled`.
- During subscription grace, explain that retained rules remain recoverable. After grace they are disabled, not silently deleted.

## Verification

Test success, insufficient scope, duplicate preset, quota exceeded, suspended subscription, cross-account references, timeout, idempotent replay, and rollback. Never generate attack traffic for a test; use a bounded benign request stream to an owned service.