The API the product is built on
An API written after the fact describes what a team was willing to expose. This one is what the interface calls, which means the interesting question — can I resolve a structure under stated conditions — has an obvious answer.
What it is, and what it is not
A REST interface over the same domain services every screen and every agent calls. Resolution, comparison, impact analysis, change creation and search are API calls before they are screens.
It is not an export interface. A great many PLM APIs are a way to get data out — read a BOM, list some parts — and go quiet at exactly the point the data becomes interesting, which is when you want it under conditions.
It is also not a second implementation. There is no separate API layer with its own idea of what a structure contains, so an API answer and a screen answer cannot disagree. That property is worth more than any endpoint on the list.
The mechanism: resolution is a first-class call
The call that matters takes a structure and a set of conditions — a date, a unit number, a plant, an option selection, a revision policy — and returns one configuration, with the reason each dropped line was dropped.
That is the difference between an API you can build on and one you can only report from. Fetching a stored BOM gives you a conditional statement you then have to evaluate yourself, in your code, differently from how Manufacturing PLM would — and the two answers will diverge.
Responses carry revisions. Every object reference names the revision it was read at, so a downstream system storing an answer can say what it was an answer *about*, and re-requesting the same conditions returns identical bytes because the underlying services are deterministic.
The tenant predicate applies identically. API requests establish the same context a page request does, so isolation is not a thing the API layer has to remember — it is enforced below the query builder for both.
The failure it prevents
A team builds an internal dashboard on a PLM's API: cost per product across the range, refreshed nightly. It works, and for a year everybody trusts it.
Then somebody notices the dashboard and the PLM's own cost screen disagree by four percent on one product. The cause is that the dashboard fetched stored BOM lines and summed them, while the PLM resolved the structure first — so the dashboard has been counting a 120-volt power supply that ships in no configuration anybody sells.
Nobody did anything wrong. The API offered stored lines, the team used them, and the divergence was invisible until it was large enough to notice. An API whose primary read is a resolution cannot produce that class of error, because there is no unresolved answer to accidentally build on.
How it meets the rest of the product
Authentication is per tenant with scoped tokens, and a token cannot exceed the permissions of the identity it belongs to. Field-level access control applies, so a token whose identity may not see cost gets responses without it rather than nulls that imply absence.
Writes go through the same domain services with the same rules. An API call cannot edit a released revision, cannot write an ERP-mastered field, and cannot create a change without an attributed actor — because those constraints live in the services rather than in the interface.
Every API write is an attributed audit row naming the token, the identity behind it and the action. An integration that misbehaves is diagnosable rather than mysterious.
Rate limits are per tenant and published, and a 429 carries the reset window. An API that throttles without telling you when to retry is an API people write bad retry loops against.
How it meets your ERP
The six ERP connectors are built on this API rather than beside it, which is a genuine claim about quality: the interface the connectors need is the interface you get, because there is no privileged internal path they use instead.
That also means the system-of-record matrix applies to your integrations. A token cannot write a field the matrix marks ERP-mastered, so a script somebody writes in a hurry cannot create the two-masters problem the matrix exists to prevent.
Where you want an integration the six connectors do not cover — a homegrown MES, a regional distributor portal, a customer's procurement system — the API plus webhooks is the supported path, and the connector SDK exists for cases that need the same lifecycle and retry semantics the built-in connectors have.
Where the boundary is
There is no GraphQL endpoint. A resolution takes conditions and returns a structure; expressing that as a graph query invites clients to compose requests whose cost is unbounded and whose caching properties are unclear, and the flexibility buys little against a domain this shaped.
There is also no bulk write endpoint that bypasses change control. Mass operations go through a change with an impact set and an approval, exactly as they do in the interface — an API that offered a shortcut around that would make the change process optional for anyone who could write a script.
Facts
| Same services | As the UI and the agents — no second implementation |
| Primary read | resolve() — conditions in, one configuration out |
| Responses | Carry revisions; deterministic and re-requestable |
| Isolation | Same tenant predicate, below the query builder |
| Tokens | Scoped per tenant; cannot exceed their identity |
| Writes | Same rules — no editing released revisions, no ERP fields |
| Rate limits | Published, with a reset window on every 429 |
| Not offered | GraphQL · bulk write bypassing change control |
Frequently asked
Is the API a second-class path?
No. Every screen and every agent calls the same domain services, so there is no separate API layer with its own idea of what a structure contains. An API answer and a screen answer cannot disagree, which is worth more than any individual endpoint.
Can I resolve a BOM through the API?
Yes, and it is the primary read. The call takes a date, a unit number, a plant, an option selection and a revision policy, and returns one configuration with the reason each dropped line was dropped. Fetching stored lines is possible and rarely what you want.
Are responses reproducible?
Yes. The underlying services are deterministic, so re-requesting the same conditions returns identical bytes, and every object reference names the revision it was read at. A downstream system storing an answer can therefore say what it was an answer about.
How is isolation handled for API calls?
Identically to page requests. An API call establishes the same tenant context, and the predicate is injected below the query builder for both, so isolation is not something the API layer has to remember to apply on each individual endpoint.
Can a token do more than its user?
No. Tokens are scoped per tenant and cannot exceed the permissions of the identity behind them, including field-level access control. A token whose identity may not see cost receives responses without the field at all, rather than nulls that quietly imply the value is absent.
Is there a GraphQL endpoint?
No. A resolution takes conditions and returns a structure, and expressing that as a graph query invites clients to compose requests whose cost is unbounded and whose caching properties are unclear. The flexibility buys very little against a domain shaped like this one.
Can we bulk-write through the API?
Only through a change with an impact set and an approval, exactly as in the interface. An API offering a shortcut around change control would make the change process optional for anybody able to write a script, which defeats the point of having one.