Export UML 2.5.1 XMI for code generation.

EOModeller doesn't ship a language mapping. Instead, the model is available as standard UML 2.5.1 XMI at a stable URL, so you write the transform — script, AI, or a templating engine — and own how the model becomes code.

What you'll set up

1. A personal access token (PAT) that doesn't expire every fifteen minutes the way a browser session does.
2. A curl one-liner that pulls the XMI for a specific model.
3. Optional: a local transform that turns the XMI into whatever artefact your toolchain needs.

Before you start

• An EOModeller account with at least Viewer access to the workspace containing the model.
• The model's workspace ID (or slug) and model ID. You can grab both from the dashboard URL when the model is selected: /eomodeller/edit/<workspaceId>/<modelId>.
• A terminal with curl. The examples below also use jq for token parsing — install it or substitute your own JSON extractor.

Step 1 — Mint a personal access token

The browser uses short-lived JWTs that expire after fifteen minutes. A script needs something longer-lived. EOModeller's PATs are minted from the dashboard, last until you revoke them, and grant the same access your account has.

1. Open the dashboard → Account tab.
2. Find the API tokens card.
3. Enter a memorable label (e.g. "laptop code-gen" or "GitHub Actions") and click Create token.
4. The plaintext token appears in an accent-tinted bubble. Copy it now — this is the only time you'll see it. If you dismiss the bubble without copying, mint a new one.

The token starts with the prefix eo_pat_. The prefix is intentional — it makes a leaked token spottable in logs, in git grep, and in GitHub's secret-scanner. Treat the rest like a password: don't commit it, don't paste it into chat, prefer environment variables over command-line arguments.

Step 2 — Pull the XMI

The endpoint is:

GET /api/workspaces/<workspaceId>/models/<modelId>/export/xmi

Authentication is the standard Authorization: Bearer … header. Workspace membership is enough — a Viewer-role teammate can fetch the XMI for any model they can browse.

The minimum useful curl:

export EO_TOKEN="eo_pat_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
export EO_HOST="https://api.eomodeller.com"
export WORKSPACE="my-workspace"
export MODEL="my-model"

curl -H "Authorization: Bearer $EO_TOKEN" \
     "$EO_HOST/api/workspaces/$WORKSPACE/models/$MODEL/export/xmi" \
     -o model.xmi

The response is application/vnd.xmi+xml and includes a Content-Disposition header so browsers download it as <ModelName>.xmi. The body is one uml:Model wrapping the whole model: top-level packages nested as packagedElement xmi:type="uml:Package", with nested packages recursing naturally.

Step 3 — What's in the XMI

The serialiser covers the seven first-class UML diagram types EOModeller commits to (see the notation conformance page). Specifically:

The xmi:id values are the same UUIDs / slugs the model uses internally, lightly sanitised to XML NCName rules. They stay stable across exports, so a transform script can key its output on the IDs and not have to track names.

Step 4 — Run your transform

The XMI is plain XML. Use whatever transform suits the work:

• XSLT for deterministic, audit-friendly code emission. The XMI namespaces are stable; old XSLT runs on new exports without surprises.
• Python / Node / Go with an XML parser. Walk packagedElement nodes by xmi:type and emit whatever your toolchain needs.
• An LLM with the XMI as context. Practical for one-off code-gen passes — paste the XMI in and ask for the artefact you want.

A typical bash pipeline:

curl -fsSL -H "Authorization: Bearer $EO_TOKEN" \
     "$EO_HOST/api/workspaces/$WORKSPACE/models/$MODEL/export/xmi" \
  | python3 my_transform.py \
  > generated/

The -f flag makes curl exit non-zero on HTTP failure, so your pipeline doesn't silently emit garbage from a 401 page if the token expired or got revoked.

Troubleshooting

401 Unauthorized

The token is wrong, expired (JWTs only), or revoked (PATs). For PATs, check the Account → API tokens card — revoked tokens appear faded with a "revoked" badge.

404 Not Found, "not found"

Either the workspace ID / model ID is wrong, or your account isn't a member of that workspace. The 404 is deliberate: it doesn't leak whether the workspace exists when you lack access.

200 OK but the XMI is just the model wrapper

The model has no classes / packages / associations yet. Either you're hitting a freshly-created model row, or you authored only ArchiMate content (which isn't included in XMI). Check the X-Eo-Warning response headers for confirmation.

How do I know if my XMI is "complete"?

The notation conformance page lists exactly what EOModeller commits to for each diagram type. Anything outside that scope (BPMN, C4-as-a-dedicated-notation) is post-launch.

Reference

• Endpoint: GET /api/workspaces/{workspaceId}/models/{modelId}/export/xmi
• Authentication: Authorization: Bearer <token> — accepts either a JWT access token or a PAT (eo_pat_…)
• Required access: workspace membership (Viewer role and up)
• Content type: application/vnd.xmi+xml
• Conformance: UML 2.5.1, XMI 2.5.1
• Response headers of note: Content-Disposition (filename), X-Eo-Warning (zero or more — one per skipped element)
• Token management API: POST /api/me/tokens (mint), GET /api/me/tokens (list), DELETE /api/me/tokens/{id} (revoke)