Destinations

Planometry table

A destination connection pointing at a Planometry table URL and API key, created the same way as any other connection on Nia Core. Because Planometry's schema is introspectable, the usual mapping editor works unchanged — map source columns to Planometry's fields just like mapping to any other connector.

HTTPS endpoint

An address you control, plus how to authenticate to it (an API key, a bearer token, or basic auth). An arbitrary endpoint has no schema to introspect, so mapping falls back to entering target field names by hand.

Allowing a destination on the agent

For a job published from a Nia Core workflow, the agent will refuse to deliver anywhere that isn't on its own local allow-list — this covers Planometry's address and any HTTPS endpoint equally. A workflow can't quietly start sending your data somewhere new; you decide what's reachable, on the agent machine itself:

nia-agent destinations allow <destination-hostname>

nia-agent destinations list

nia-agent destinations remove <destination-hostname>

If a published job's destination host isn't allowed, the agent rejects it locally with "destination not on local allow-list" — visible on the Agents page.

Jobs created directly on the agent machine with nia-agent job add aren't affected by this list.

What gets sent where

• The agent sends the actual rows straight to the job's destination — Nia Core's platform never sees row data.
• Nia Core only receives a status summary: job name, source table, destination type and host, schedule, and health — plus, per run, success/failure, row count, duration, and (on failure) a general error category, never the detailed error text.

Full detail in Security.