API / CLI access

Send signals in. Read signal data back.

PingMyThing exposes simple HTTP paths for systems that need to send selected outcomes, and for tools that need to read stored signal data back.

Use the browser view when that is enough. Use the API or CLI when PMT data needs to feed a script, report, NOC view, notebook, or your own application.

The API returns stored telemetry. It does not diagnose causes or replace the webapp’s display rules.

Get your signal

Two API directions

Send
A source submits a small GET or POST signal to ingress.

Read
A client queries stored signal data through egress.

Interpret
Your script, webapp config, or operator decides what the values mean.

Use API access when PMT needs to be a component

PMT is useful as a browser view, but it is not limited to the browser.

API / CLI may fit if

you want a script to send selected outcomes
you want to read latest signal data into another tool
you want simple reporting without exporting manually
you want a small operational view built from PMT data
you need the same signal layer across scripts, apps, sites, devices, or branches

API / CLI may not fit if

you expect PMT to run checks remotely
you expect API responses to diagnose root cause
you need guaranteed delivery, storage, or processing
you want high-volume metric streaming
you want the read API to return webapp-only interpretation

PMT reflects stored signals. It does not infer meaning.

Send endpoint

Ingress accepts small signals using either POST JSON or GET query parameters.

Endpoint
https://ingress.pmtapi.net/v2/

Common public fields:

tkn — send token
stn — station, site, device, job, or source name
sens — short stable signal/check name
val — submitted state or scalar value
tag — optional short grouping label

Keep meaning at the source

The source decides what to send.

A backup script may send a backup result. A website check may send reachability. A device may send a scalar value. PMT accepts the submitted signal for processing and makes stored telemetry available for display or readback.

Use stable names. Treat sens as a short string such as backup_result, site_reachable, or system_free_gb.

Simple send examples

Keep tokens out of page examples and scripts where possible. Use environment variables or your local secrets mechanism.

POST JSON

curl -sS -X POST https://ingress.pmtapi.net/v2/ \
  -H "Content-Type: application/json" \
  -d '{
    "tkn":"$PMT_SEND_TOKEN",
    "stn":"web01.example.net",
    "sens":"site_reachable",
    "val":-1,
    "tag":"web"
  }'

GET query string

curl -sS "https://ingress.pmtapi.net/v2/?tkn=$PMT_SEND_TOKEN&stn=web01.example.net&sens=site_reachable&val=-1&tag=web"

Read endpoint

Egress lets your own tools query stored PMT telemetry.

Endpoint
https://egress.pmtapi.net/egress/v3/query

Typical query options include:

tkn — one or more read tokens
pin — where a PIN is required
stn or stations — station filters
sens or sensors — signal filters
tag — short grouping filter
latest_stn, latest, or latest_n — query mode

What readback returns

The read API returns stored values and timestamps. It is suitable for scripts, reports, custom dashboards, notebooks, or integrations.

Stored telemetry is not root cause. It is the signal that was submitted and stored.

Simple read examples

Use a read token, not a send token, when pulling data into another tool.

Latest per station and signal

curl -sS -X POST https://egress.pmtapi.net/egress/v3/query \
  -H "Content-Type: application/json" \
  -d '{
    "tkn":["$PMT_READ_TOKEN"],
    "latest_stn":true,
    "limit":100
  }'

Filter one station and signal

curl -sS -X POST https://egress.pmtapi.net/egress/v3/query \
  -H "Content-Type: application/json" \
  -d '{
    "tkn":["$PMT_READ_TOKEN"],
    "stn":"web01.example.net",
    "sens":"site_reachable",
    "latest_n":10
  }'

Useful API / CLI patterns

Use PMT as a small signal layer, not as a place to move all operational data.

Script reporting

A scheduled task, cron job, backup script, or application submits one selected outcome.

Good fit: backup_result, job_complete, reboot_pending.

Custom dashboard

Your own view queries latest stored telemetry using read tokens and filters.

Useful when PMT data needs to sit beside other operational information.

Reporting / notebooks

Pull stored signal history into a script, spreadsheet, pandas notebook, or reporting layer.

Interpretation remains outside PMT.

Token safety

Treat tokens as credentials.

Use send tokens for sending.
Use read tokens for querying.
Use environment variables or local secrets where possible.
Do not paste live tokens into public docs, screenshots, tickets, or examples.
Rotate or revoke exposed tokens.

Use project-specific tokens so signals land in the intended separated project.

What not to send

PMT works best when the payload is small and intentional.

do not send passwords or API keys
do not send raw logs or file contents
do not send broad telemetry just because you can
avoid personal or regulated data unless there is a clear basis
prefer small outcomes and scalar values

If a value does not change what someone does, it probably does not belong in PMT.

What API access does not change

API access does not turn PMT into a control plane.

PMT does not run your checks remotely
PMT does not discover systems
PMT does not collect inventory
PMT does not diagnose causes
PMT does not guarantee delivery or storage of every signal
PMT is not a compliance archive

It receives selected signals and makes stored telemetry available.

Where to go next

If you want a no-scripting first path, start with transparent starter checks.

If you want custom logic, build one small sender and one clear signal name.

If you need multiple customers or sites, use separate projects and project-specific tokens.

Use PMT as a small signal layer

Send selected outcomes in.
Read stored signal data back.
Keep interpretation where it belongs.

Get your signal