Choosing an API

Lurana BPM exposes two HTTP APIs. They do different jobs, and most integrations only need one of them.

	Workspace API	Classic REST API
Base	/{workspace}/{language}/lurana/api	/api/1.0/{workspace}/
Authentication	Login returns an access token and a refresh token	OAuth2 bearer token from a registered client
Documented	The integration surface	The supported subset
Best for	New integrations, and anything the application itself does	Integrations already built on it, and operations only it has

Which one

Start with the workspace API. It is the surface the application uses, it is documented page by page, and it covers authentication, the case workspace, search and user provisioning.

Use the classic API when you need something the workspace API does not expose:

• advanced search filters, saved per user;
• bookmarks on start tasks, and the list of starting tasks;
• uploading into a case variable, and executing a trigger on a case;
• case notes with paging, and the per-delegation variable endpoints;
• supervisor information, batch reassignment and impersonation;
• the process permissions and the starting tasks of a user.

The two share a data model but not their responses: the classic API returns the legacy field names (APP_UID, DEL_INDEX), the workspace API returns its own shapes. Pick one per integration rather than mixing them.

What is not documented

The classic API has 534 routes. The 392 left out of this guide are:

• the mobile client (Light), deprecated;
• the deprecated analytics (Dashboard, ReportingIndicators) and the overloaded Consolidated;
• System, Catalog, Process, Test and Metrics;
• the administration resources the new Admin screens replace: users, groups, roles, departments, calendars, email servers and process categories;
• the designer editing its own objects, which is what the Designer interface is for.

If an integration needs one of them, tell us: they are supported by the product, just not part of the documented contract.