Home / TAOM™ Platform & API – process data through the interface

TAOM™ Platform & API – process data through the interface

For development and enterprise IT

The interface – what it does and how to call it.

TAOM makes processes, attributes and functions available through an interface. This page describes what it is for and what an access token looks like. It does not replace a full reference – customers receive that with their access.

Basics

Four things up front

Versioned

The interface sits under a versioned namespace. A new version does not silently replace the old one; existing integrations keep working.

Named access tokens

One token per connecting application, with scope, tenant and expiry date. Revocable individually, usage is recorded.

Scope instead of full access

Read only, read and write, or full access. Deleting requires the highest level. The scope is checked on every call.

Tied to a tenant

If a token carries a tenant, it reaches only that tenant’s workspaces – whatever identifier is sent along.

Authentication

One header field, nothing more

GET https://your-environment/wp-json/taom/v1/…
Authorization: Bearer <your access key>

The key is shown once when the token is created and afterwards kept only as a checksum. It belongs on the server, never in a browser application.

Responses come as JSON. Errors carry a code and a message; insufficient scope is rejected and logged instead of failing silently.

Areas

What you can address

Workspaces and models

Create, read, change, fetch versions. Plus phases, metadata, groups of several diagrams and the provenance seal – every model file generated carries it, and it can be verified without access to TAOM.

Enrichment

Start a run, query its state, fetch the result – for a single element or the whole model.

Events from Jira and Confluence

Status changes in Jira and changed text sections in Confluence report back to the model through our own Atlassian app. Which side owns which value is defined field by field. Outbound, return and field ownership →

Attachments

Upload, list, fetch and remove documents – bound to the element they belong to.

Agents

Directory, style profile, library, plus request and result of a run.

Users and licence

Sign-in, account, licence state – the basis for another application acting on behalf of an authorised user.

Presence

Who is working on a model right now. This lets collaboration be reflected outside the interface too.

Two patterns

What an integration usually looks like

Pull

The other application asks, TAOM answers. Suitable for reports, overviews and anything that wants to read the current state.

Job and callback

A run is triggered, TAOM answers immediately with an acknowledgement and reports the result later to a registered address. Necessary because an agent run takes longer than a request may wait.

Two properties we guarantee: The same call twice does not produce two results. And every callback carries the identifier of the element it belongs to – so the mapping does not have to be guessed.

Recently possible

Query across all workspaces

Querying across the whole inventory works: by attribute, with free text or through thirteen ready-made questions – for instance “inspection required but no test case”. The answer names model, phase and role per hit.

How this looks in the tool →

Not there yet

What we should honestly add

Suggestions while modelling

The library from the Learning Model is in place. Offering it as a suggestion while typing is implemented in one place only.

Rate limits

Per-token limits are planned but not yet set.

We list this here because an interface description without gaps is not one. What is missing stands on the same page as what works.