tedi

The official command-line client for the Tediware platform.

tedi is a thin client over the Tediware API — no proprietary logic and no licensed data live in the CLI. Its first capability is X12 reference lookup, and it is built to grow into a control-plane companion for the platform.

Install

npm install -g @tediware/tedi

Quick start

tedi auth login            # paste your API key (entered without echo)
tedi x12 seg N1            # look up an X12 segment
tedi x12 txn 856           # look up a transaction set
tedi x12 ele 235           # look up an element and its code list
tedi edi obfuscate f.edi   # scrub personal data from an EDI file (local, no server)

Authentication

All commands that talk to the Tediware platform require an API key; local edi file operations run without one. Create a key in the Tediware dashboard (sign up and accept the service terms there first, then head to https://tediware.com/app/api-keys), then provide it to the CLI. The key is never passed as a command-line flag, so it can't leak into shell history or process listings.

tedi auth login            # prompts for the key with no echo, then stores it
cat key.txt | tedi auth login   # or pipe it in (CI/non-interactive)
export TEDI_API_KEY=...    # or set it in the environment (one-off / CI; no login needed)

tedi auth status           # show whether you're signed in
tedi whoami                # show the authenticated identity (when available)
tedi auth logout           # clear stored credentials

TEDI_API_KEY overrides any stored key at request time. Stored credentials live in a permissioned file in the CLI config directory today; OS-keychain storage is a planned drop-in. X12 reference access additionally requires that your account has accepted the current Tediware service terms; the server enforces this on every request.

A browser device-flow login is the eventual destination but is deferred; it will slot in under the same stored-key model without changing how you use the CLI.

X12 reference

tedi x12 seg <id>        # e.g. tedi x12 seg N1   (alias: segment; case-insensitive)
tedi x12 txn <id>        # e.g. tedi x12 txn 856  (alias: transaction; case-insensitive, SH856 also accepted)
tedi x12 ele <id>        # e.g. tedi x12 ele 66   (alias: element; case-insensitive)
tedi x12 releases        # list supported X12 releases

Every x12 command accepts:

• --release / -r <id> — the X12 release to look up (e.g. 004010, 005010). Defaults to the x12.release config value, or 004010 if unset.
• --format console | markdown — output format (default console). The licensed X12 standard is presentation-only: --json is intentionally not offered for reference data and returns an explanatory message. Structured --json is for your own org data in future control- and data-plane commands.

Colored console output is requested only when stdout is an interactive terminal and color hasn't been disabled (--no-color / NO_COLOR). markdown is never colored, so piped and redirected output stays clean.

EDI files

Local operations on your own EDI files. edi obfuscate runs entirely on your machine: your file never leaves it, and no API key is needed. (Future edi commands may be server-backed; locality is a per-command property, stated in each command's help.)

tedi edi obfuscate <file>              # obfuscated EDI to stdout ('-' reads stdin)
tedi edi obfuscate claims.edi -o clean.edi   # write to a file instead
tedi edi obfuscate claims.edi --seed s       # reproducible replacements

edi obfuscate replaces personal data in an X12 interchange with format-preserving fakes: person names, street addresses, city/ZIP (first three ZIP digits kept), dates of birth (year kept), phone/fax/email, SSNs, member and medical-record identifiers, patient account numbers, bank routing/account numbers, and free-text notes. The same value always maps to the same replacement within a run, so cross-segment references stay intact.

Everything structural survives byte-for-byte: delimiters, qualifiers, code values, dates of service, monetary amounts, control numbers, segment counts, and element lengths (including the fixed-width ISA header) — an obfuscated file parses exactly like the original. Business identifiers (sender/receiver routing IDs, organization names, NPIs, tax IDs) are kept so the file stays debuggable.

Replacements are randomized per run and not reversible; --seed derives them from the given seed instead, for reproducible output. This is a best-effort scrub for sharing files in debugging contexts, not a certified HIPAA de-identification: review the output before sharing, especially free-text-heavy files.

Configuration

tedi config list                       # show all config values and their sources
tedi config get x12.release
tedi config set x12.release 005010

| Key | Env override | Default | | ------------- | ------------------- | ---------------------- | | x12.release | TEDI_X12_RELEASE | 004010 | | api.baseUrl | TEDI_API_BASE_URL | https://tediware.com |

The config directory can be relocated with TEDI_CONFIG_DIR.

Updating

tedi update              # upgrade to the latest published version
tedi update --version X  # install a specific version

tedi update reinstalls the CLI from npm (npm install -g @tediware/tedi@latest) and then prints the new version's changelog. The CLI also checks for updates in the background (throttled, cached) and shows a non-interrupting nudge when a newer version is available; you can always upgrade manually with npm install -g @tediware/tedi.

Development

This is a oclif (TypeScript, ESM) project.

npm install
npm run build          # compile to dist/
./bin/run.js --help    # run the built CLI
./bin/dev.js --help    # run straight from TypeScript source
npm run lint           # type-check
npm test               # run tests
npm run check:licensed-data   # licensed-data tripwire (also runs in CI)

By default the CLI talks to the real Tediware API — api.baseUrl defaults to the production host (https://tediware.com), so you just need a key (the HTTP contract is documented in API.md):

export TEDI_API_KEY=<api-key>     # or `tedi auth login`
tedi x12 releases

For local development without a live server or a real key, opt into a synthetic mock backend with TEDI_API_MOCK=1 (any non-empty key works as a token there):

export TEDI_API_MOCK=1
export TEDI_API_KEY=sk-dev-anything
tedi x12 releases

Maintainers running the Tediware server locally (it lives in a separate, private repo) can point at it with tedi config set api.baseUrl http://localhost:5004.

Note: the mock backend's reference content is synthetic placeholder data for development only. It is not licensed X12 reference content.

Releasing

Releases are tag-driven. Bump the version and push the tag:

npm version <patch|minor|major>
git push --follow-tags

Pushing a v* tag triggers .github/workflows/release.yml, which builds, tests, publishes to npm with provenance via OIDC trusted publishing (no stored token), and creates the GitHub Release whose notes power tedi update's changelog. See CONTRIBUTING.md for the one-time npm trusted-publisher setup.

Contributing

Contributions are welcome under the DCO — sign commits with git commit -s. See CONTRIBUTING.md.

One hard rule: never commit licensed X12 data (including test fixtures and recorded responses). A CI tripwire guards against it.

License

Apache-2.0.