Skip to main content

How profiles reach a machine

Read this before integrating if your goal is to get a profile onto a machine. The short version:

Machines pull; nothing pushes to them

A machine periodically contacts Pathfinder Edge, authenticates with its own serial number and registration key, and downloads whatever changed in the catalogs it is subscribed to. The Published API has no endpoint that sends a profile to a machine, and no way to trigger, force, or expedite a sync. An API key does not authenticate a machine and cannot act on one.

This is deliberate: a machine on a shop floor decides when it is ready to accept new work.

What the API does, then​

POST /api/v1/profiles writes to your library. That is the whole job. If the profile lands in a catalog the machine subscribes to, the machine picks it up on its next poll — no second call, no publish step, nothing to enable.

So an integration only controls one thing that affects machine delivery: which catalog the profile lands in.

What determines whether a machine receives a profile​

All of these must hold:

  1. The profile is in a catalog the machine subscribes to. Set under Admin > Machines > (your machine) — only checked catalogs reach that machine. This is the filter integrations get wrong most often.
  2. The profile is not archived. Deleting a profile archives it, and that removal syncs too.
  3. The machine is connecting. A machine that is powered off, off the network, or blocked receives nothing, and nothing about the library changes that.

There is no publish or approval flag, and no per-profile switch. A profile created through the API is treated exactly like one saved in the web editor — same filter, same schedule. Profiles are also re-sent when they move between catalogs, and adding a catalog to a machine re-sends that whole catalog.

What the machine receives​

Profile name, description, category and subcategory, the feature list, the computed blank width, painted side, and a rendered thumbnail.

description is the field to use for a note you want the operator to see — it travels with the profile. Per-feature name values do not travel to the machine; they are library-side labels for your own cross-referencing.

Troubleshooting: a profile is in the library but not on the machine​

Work down this list — it is ordered by how often each is the cause.

  1. Confirm the profile's catalog. GET /api/v1/profiles/{id} returns owningCatalogId. Compare it against the checked catalogs under Admin > Machines > (your machine). Note that catalog names are not unique — two catalogs can have names differing only in case, so match on the id, never the name.
  2. Confirm the machine is connecting. Admin > Machines shows each machine's last connect time and whether it has unsynced updates pending. If the last connect is stale, the problem is the machine's connectivity, not your API call — nothing in the library will help until it polls.
  3. Confirm the machine is not blocked or inactive. A blocked machine silently receives an empty change set.
  4. Check the profile is not archived. A profile deleted through the API stops being returned by GET /api/v1/profiles.
  5. Re-read the echoed POST response. owningCatalogId and blankWidth in the response are what the server actually stored, which may not be what you intended to send. If you omitted owningCatalogId, the profile went to your default catalog — which may not be the one the machine subscribes to.

If all five check out, contact support with the profile id and the machine serial number; the server-side record for that profile and that machine's sync history can be read directly.