claudetools/session-logs/2026-06/2026-06-22-mike-packetdial-domain-onboarding-vwp.md

Session — packetdial domain onboarding: GUI→API mapping, created vwp.91912.service (capability test)

User

• User: Mike Swanson (mike)
• Machine: GURU-5070
• Role: admin

Session Summary

Continued the packetdial/NetSapiens work toward giving the skill the ability to onboard a new client (domain). Discussed the nuanced aspects of adding a domain to the PBX, then Mike supplied six screenshots of the OITVOIP "Add a Domain" GUI wizard (tabs: Basic, Defaults, Limitations, Emergency) filled in for a real client, Valley Wide Plastering. Goal: determine whether the domain could be created via the API from the wizard data alone.

Reverse-engineered the wizard into a 3-call API flow by reading the OpenAPI schemas and grounding field formats against the live arizonacomputerguru domain + its E911 address: (1) POST /domains carries Basic + Defaults + Limitations; (2) POST /domains/{domain}/addresses/validate returns the address-formatted-pidflo + an emergency-address-id; (3) POST /domains/{domain}/addresses creates the E911 address with that pidflo. Built the field→property mapping (e.g. GUI Name+suffix → domain=vwp.91912.service + reseller=91912.service; Dial Permission → dial-policy; the Limitations tab → limits-max-*; Emergency tab → the address validate/create bodies).

Executed the live creation after Mike confirmed the address (301 N 56th St, Chandler AZ 85226) and phone ((480) 705-9500). All three calls succeeded: vwp.91912.service created (reseller 91912.service, America/Phoenix, US-and-Canada dial-policy, auto-generated dial-plan); the E911 address validated (USPS VALID, auto-adjusted +4 to 85226-2502, pidflo generated); the address created and verified on the domain (id a-6a395c03d4cfe). Capability proven: a domain CAN be onboarded from the wizard data via the API.

Identified the gaps vs. the full GUI wizard for productizing this into an onboard-domain wrapper: voicemail user-defaults (Enable/Transcription/Message) are NOT in the POST /domains schema (the GUI applies them as user-creation defaults — home still TBD); domain-type did not map (sent "Standard", came back "no"); and email-send-from-address was left blank — Mike noted the eventual sender should be voicemail@packetdial.com / noreply@packetdial.com, which must be created first (ACG's own domain uses notify@oitvoip.com as the working pattern). The keep-or-delete decision on the live vwp.91912.service is pending Mike's answer.

Key Decisions

• Treated it as a real client create, not a throwaway — once Mike clarified vwp wasn't yet created and the data was real (Valley Wide Plastering, real E911), staged it with explicit payload review before firing rather than guessing, because a wrong 911 address is safety-critical.
• 3-call orchestration (domain → address validate → address create), because the E911 create REQUIRES address-formatted-pidflo, which only the validate step generates.
• "unlimited" limits → omit the limits-max-* fields (they defaulted to 0 = uncapped). Matches the GUI "unlimited"; avoids guessing a sentinel.
• Omitted email-send-from-address (GUI showed the grey placeholder, not an entered value) and dial-plan (auto-generates, named after the domain, like arizonacomputerguru).
• Grounded field formats against a live domain before building the payload (dial-policy literal "US and Canada"; SSO/MOH are "yes"/"no" strings; area-code/caller-id are numbers; country US, state AZ, city UPPERCASE) — avoided format-mismatch failures on the real create.

Problems Encountered

• domain-type didn't map — sent "Standard", the create stored "no". Cosmetic; fixable via update (PUT /domains/{domain}). The live ACG domain shows "Standard".
• Voicemail defaults have no home in POST /domains — the GUI Defaults tab (Enable VM, Transcription, Message) isn't represented in the domain-create schema; they are user-creation defaults applied elsewhere. Unresolved — needs the Network-tab capture or test to find the call.
• pidflo is not XML — address-formatted-pidflo is a structured object (HouseNumber/StreetName/.../ValidationStatus:VALID/Adjusted:true), not a PIDF-LO XML string. Passed the validate response object straight into the create body to carry it verbatim (avoids command-line quoting of the nested object).
• Earlier (carried context): /tmp path mismatch and cp1252 JSON-read errors on Windows — handled by repo-relative paths + encoding='utf-8' (documented gotchas).

Configuration Changes

• No repository file changes this session (analysis + live API writes against the PBX).
• Scratch (gitignored): .claude/tmp/ns-openapi.json (spec), .claude/tmp/vwp-validate.json (validate response used to build the address-create body).
• Live PBX change: created domain vwp.91912.service + its E911 address (see below).

Credentials & Secrets

• No new credentials. Used the vaulted OITVOIP reseller key (msp-tools/oitvoip.sops.yaml → credentials.api_key, key-id nsr_hSGUB5Wo) via the packetdial skill.
• Pending infra: voicemail@packetdial.com / noreply@packetdial.com mailboxes need creating, then set per-domain as email-send-from-address (so voicemail-to-email delivers). ACG's domain uses notify@oitvoip.com.

Infrastructure & Servers

• NetSapiens/PacketDial reseller PBX: https://pbx.packetdial.com/ns-api/v2 (v44.4.10). Reseller 91912.service.
• Created this session: domain vwp.91912.service (Valley Wide Plastering) — reseller 91912.service, tz America/Phoenix, dial-policy "US and Canada", dial-plan vwp.91912.service (auto), caller-id 4807059500, emergency caller-id 4807059500. Status: LIVE (keep/delete pending).
• E911 address on vwp: id a-6a395c03d4cfe — Valley Wide Plastering, 301 N 56TH ST, CHANDLER, AZ 85226 (USPS VALID, adjusted +4 → 85226-2502), location "Main".
• Reseller domains now: arizonacomputerguru, 0000.91912.service, russo.91912.service, vwp.91912.service.

Commands & Outputs

• Create domain: ns.py create-domain --body '{"synchronous":"yes","domain":"vwp.91912.service","reseller":"91912.service","description":"Valley Wide Plastering","domain-type":"Standard","dial-policy":"US and Canada","time-zone":"America/Phoenix","area-code":480,"caller-id-name":"Valley Wide Plastering","caller-id-number":4807059500,"caller-id-number-emergency":4807059500,"single-sign-on-enabled":"no","music-on-hold-randomized-enabled":"no"}' --confirm
• Validate E911: ns.py raw POST domains/vwp.91912.service/addresses/validate --body '{...address...}' --confirm → returns pidflo object + emergency-address-id.
• Create E911: ns.py create-address vwp.91912.service --body '{...validated + pidflo + id...}' --confirm → verified 1 address on domain.
• Delete (if removing): ns.py raw DELETE domains/vwp.91912.service --confirm.
• Set email sender later: ns.py raw PUT domains/vwp.91912.service --body '{"email-send-from-address":"voicemail@packetdial.com"}' --confirm.

Pending / Incomplete Tasks

• DECISION PENDING: keep vwp.91912.service (real client; then close gaps below) or delete it (capability test only) and fold the flow into an onboard-domain wrapper.
• If keeping: fix domain-type → Standard; set email-send-from-address once the packetdial.com mailbox exists; apply voicemail defaults (mechanism TBD).
• Productize: build a gated onboard-domain wrapper running the verified 3-call flow from one JSON body (Basic/Defaults/Limitations/Emergency), with the address validate→create chained.
• Resolve the voicemail-defaults call — capture the GUI Network tab, or test, to find where the Defaults-tab VM settings persist.
• Create voicemail@/noreply@packetdial.com mailboxes (separate infra task).

Reference Information

• Skill: .claude/skills/packetdial/ (ns.py, ns_client.py, SKILL.md, references/api.md).
• Spec: pbx.packetdial.com/ns-api/webroot/openapi/openapi.json (local scratch copy .claude/tmp/ns-openapi.json).
• Endpoints used: POST /domains, POST /domains/{domain}/addresses/validate, POST /domains/{domain}/addresses, GET /domains/{domain}, GET /domains/{domain}/addresses.
• Vault: msp-tools/oitvoip.sops.yaml (key-id nsr_hSGUB5Wo).
• Created objects: domain vwp.91912.service, E911 address a-6a395c03d4cfe.