The Teamcenter API an AI agent should use is Teamcenter Services (SOA), called as JSON over the web tier at /tc/JsonRestServices under the person's own session. Reading one BOM takes five calls, from login to closeBOMWindows, and the revision rule must be explicit. A server for agents should wrap that sequence in named MCP tools, not expose raw services.
Five things called the Teamcenter API
| Surface | What it is | For an agent's server |
|---|---|---|
| Teamcenter Services (SOA) | Siemens' service layer, with Java, C# and C++ client bindings in strongly and loosely typed variants | The contract to build against. Use the bindings when the server is written in Java or .NET |
| JsonRestServices | The same services called as HTTP POST with a JSON body, e.g. /tc/JsonRestServices/Core-2011-06-Session/login. Active Workspace uses this path itself | Workable from any language; payloads follow the SOA operations, and public JSON documentation is thin |
| Active Workspace internal services | View-model services the Active Workspace client calls, e.g. Internal-AWS2-2019-06-Finder/performSearchViewModel4 | Avoid. They are named internal and shaped for a screen, not for a stable contract |
| Product Cost Management REST API | The one Teamcenter REST API on Siemens' developer portal, for product cost and carbon footprint in Teamcenter X | Only if the question is cost. It does not read the product structure |
| Mendix Teamcenter Connector | Siemens' Mendix module for building apps on top of Teamcenter | A route for building apps, not a service an agent calls |
Siemens also publishes an official Teamcenter API workspace on Postman. What developers still ask for, in a community question on Teamcenter 2412, is public documentation with JSON schemas for the loose-typed operations.
Where it breaks
01 · Configuration
createBOMWindows takes a revRuleConfigInfo block: the rule, plus date, unit and end-item effectivity. The community Postman collection that ranks for this very query sends the rule as an empty string with today set to true. A tool that does the same answers from whatever configuration applies, and the person asking has no way to see which one it was.
02 · State
Reading a structure is not one request. It is login, resolve the item, open a BOM window, expand it, close the window. The window lives on the server between those calls. A tool that fails after the open and before the close has to close anyway, which a model improvising the sequence will not reliably do.
03 · Identity
The login call carries user, group and role, and Teamcenter evaluates access for that session. Every later call inherits it. Log in once with a shared account and every answer the agent gives, to every person, carries that account's rights, whatever the individual asking may see.
04 · Documentation
Operation names such as Cad-2007-01-StructureManagement/expandPSAllLevels encode a library, a release date and a service, and the payloads follow the SOA definitions. The public route to exact JSON is thin: developers work from Postman collections and from API definitions generated inside an Active Workspace build.
The first shortcut is a service account on the SOA layer. It is quick: one login in a config file, the client bindings, a handful of calls, and the demo answers questions about any part in the database within a day. It passes every functional test, because the service account can see everything. That is also why it fails the first security review worth the name. In a Teamcenter that holds programmes under export control, an agent answering every employee with one account's rights is a disclosure path, and nobody will sign it.
The second shortcut is quieter. Open Active Workspace in a browser, record which services it calls, and replay them. The internal view-model services return exactly what the screen shows, already filtered and formatted, which looks convenient.
They are named internal for a reason. A view-model service is shaped for one screen in one release, so an upgrade that changes the screen can change the response, and nothing in a public contract warns you. Building an agent's tools on them trades a week of work now for a rebuild at the next upgrade.
What we build instead sits between the two: the published Teamcenter Services operations, called as JSON over the web tier, under the session of the person asking, and wrapped in a small number of named tools that fix the revision rule, close every window and never reach a write operation. It is slower to start than either shortcut. It is the version that is still correct after the next release and still signable after the next review. We have not yet built it for a named customer, and the argument here rests on what the API exposes and what a PLM owner will ask, not on a delivered project.
The sequence behind one BOM read
The endpoints and payload shapes come from a public, MIT-licensed community Postman collection; host, port and identifiers are placeholders. The comments mark the two places a tool has to be stricter than the example.
# Teamcenter API: read one product structure through JsonRestServices.
# Every call is POST {web tier}/tc/JsonRestServices/<Library>-<YYYY>-<MM>-<Service>/<operation>
# 1. Session. Carries user, group and role; every later call inherits it.
POST /tc/JsonRestServices/Core-2011-06-Session/login
{ "header": { "state": {}, "policy": {} },
"body": { "credentials": { "user": "<person>", "password": "<from SSO, never a config file>",
"group": "", "role": "", "locale": "" } } }
# 2. Resolve the item to a UID.
POST /tc/JsonRestServices/Core-2007-01-DataManagement/getItemFromId
{ "body": { "infos": [ { "itemId": "<part number>", "revIds": ["A"] } ], "nRev": 1 } }
# 3. Open a BOM window. The public example sends "revRule": "" here. A tool must not:
# pick the rule from Cad-2007-01-StructureManagement/getRevisionRules and name it.
POST /tc/JsonRestServices/Cad-2007-01-StructureManagement/createBOMWindows
{ "body": { "info": [ { "item": "<item uid>",
"revRuleConfigInfo": { "revRule": "<named revision rule>",
"props": { "today": true, "unitNo": -1, "endItem": "", "endItemRevision": "" } } } ] } }
# 4. Expand from the top line.
POST /tc/JsonRestServices/Cad-2007-01-StructureManagement/expandPSAllLevels
{ "body": { "input": { "parentBomLines": ["<top bom line uid>"], "excludeFilter": "None" },
"pref": { "expItemRev": false } } }
# 5. Close the window. Always, including when step 3 or 4 failed.
POST /tc/JsonRestServices/Cad-2007-01-StructureManagement/closeBOMWindowsFive calls, one of them stateful and one of them easy to leave unconfigured. That is the unit an MCP tool should hide: get_structure(part, revision_rule, date) runs all five, closes the window on every path and returns the rule it used next to the lines.
What the API gives, what the tool adds
When to stay inside Teamcenter
If every question your users ask can be answered from Teamcenter alone, Siemens’ own Copilot and the AI BOM agent added in release 2606 are maintained through your upgrades and need no server of yours. Build on the API when the answer needs something Teamcenter does not hold: the plant BOM in SAP, a failure trend in a historian, a second PLM after an acquisition. That is where the connector described under Teamcenter integration starts.
Not in the resource-style sense, but you can call it over HTTP with JSON. Teamcenter Services, the SOA layer with Java, C# and C++ bindings, can be called as HTTP POST requests with a JSON body under /tc/JsonRestServices, and Active Workspace uses that path itself. The operation names and payloads are the SOA ones, so what you are learning is the service catalogue. The one Teamcenter REST API listed on Siemens' developer portal covers product cost management, not product structure.
No, not for anything that reads across programmes. The login call carries a user, a group and a role, and Teamcenter evaluates access for that session. A service account therefore answers every person with the service account's rights, which is how an export-controlled structure ends up in front of someone outside the programme. The server should hold the person's session, through single sign-on where your installation uses it, and narrow its tools where that is not possible.
The entry is a fixed-price Readiness Blueprint at €4,900 over two weeks: one use case, the tool list agreed with your PLM owners, a test of per-person sessions on your instance, and a costed build plan. A first production server is typically a pilot from €15,000. Whether API or service users carry licence terms of their own under your Siemens contract is a question for Siemens; check with them. All prices are net and exclude VAT.
It cannot tell you which revision rule a question should be answered under. That is a business decision, and a tool has to make it explicit rather than guess. It also does not make a heavily customised data model portable: Teamcenter installations extend their business objects, so the tool list is written against your instance and tested there, not copied from another. And it offers write operations right next to the read ones, which a tool list has to leave out on purpose.
Then we run it, inside your environment rather than ours. The server is your code in your repository, deployed next to your Teamcenter web tier, and the handover includes the tool definitions, the contract tests and the runbook. If you want us to operate it afterwards, monitoring starts at €3,000 per month. A hosted service outside your network is technically possible, and for engineering data under export control it is usually the harder approval.
Next step
Two weeks, fixed price: we agree the first Teamcenter tools with your PLM owners, test whether each person's session can be carried through on your instance, and hand back a costed plan for the server.