Developer interfaces

Understand how future APIs and developer tools can extend Paraline without bypassing its business rules.

Some organizations will use Paraline through the product interface. Others will need to connect internal applications, partner systems, workflows, or custom software.

Paraline is intended to support those extensions through APIs, developer libraries, and MCP. Each interface should work with the same records, actions, permissions, workflow state, and history.

There is no public production API or SDK today. This article explains the design direction rather than released endpoints or packages.

One operating layer, several ways to use it

Product interface: Helps people model, review, operate, and improve a workspace visually.
API: Allows applications and integrations to retrieve data, request business actions, and receive events through versioned contracts.
SDK: Gives developers typed helpers for defining modules and working with Paraline concepts.
MCP: Lets compatible AI applications discover permitted context and tools through an open protocol.

These should be different doors into the same building. An action invoked from an API should not bypass the permission or history that applies when a person uses the product.

Prefer business actions to generic updates

An API often needs ordinary record operations. Consequential changes should also be available as meaningful business actions.

resolve_case can check the current state, require resolution evidence, close open tasks, record an event, and begin customer communication.

A generic update_record call can change the status field, but every caller would need to recreate the surrounding rules correctly.

Business actions make integrations easier to understand and safer to evolve. The caller asks for a recognizable outcome, and Paraline remains responsible for validation, permission, and history.

Qualities of a dependable interface

Quality	What it means for the business
Typed	Inputs, results, events, and errors have a known structure
Scoped	Every credential and actor has limited workspace, data, and action access
Safe to retry	Repeating a request does not duplicate an effect when stable identity is available
Observable	Important calls can be traced to an actor and result
Versioned	Interfaces can change through declared compatibility and migration
Agent-legible	Tools and errors are structured enough for software to interpret
Human-governed	High-impact actions can be previewed and approved

Errors should be useful. A caller needs to distinguish invalid input, missing permission, conflicting state, an unavailable service, required approval, and a request that already completed.

A declarative development model

Paraline’s intended SDK direction is to let a developer describe a business capability through common building blocks.

const repairManagement = defineModule({
  name: "repair-management",
  objects: [repair, asset, customer],
  views: [repairQueue, repairDetail],
  actions: [assignRepair, markReady],
  workflows: [notifyWhenReady],
});

This example is illustrative, not a released API.

The important idea is that the module declares the operation while the runtime continues to own workspace isolation, authorization, common validation, activity history, and versioning.

Declarative modules are easier to inspect, test, compare, and upgrade than a separate custom application for every customer. Advanced code can still cross an explicit extension boundary when necessary.

Developer changes follow the publishing model

A programmatic interface should not mutate shared production configuration piecemeal.

A safer path is:

read the current definition and supported capabilities;
submit a structured proposal against a known version;
validate schemas, references, permissions, and compatibility;
preview and test the effect;
let an authorized person publish the version.

This gives AI coding tools and implementation partners room to work quickly without allowing an unreviewed request to redefine the business system.

Events connect other systems

Integrations need a way to observe important Paraline events and report external results.

A webhook that says “case resolved” should identify the workspace, record, action, timestamp, and version needed to interpret it. Delivery also needs signing, duplicate protection, retries, and failure handling.

Sending an event is not the same as completing an external responsibility. The runtime should preserve whether the recipient accepted the event and whether the downstream outcome became known.

Connections should retain provenance. If an integration reads a CRM, sends email, or updates accounting software, the history should identify the connection and external record involved.

Product boundary

A released API or SDK will need stable versions, authentication, scopes, schemas, rate and usage limits, error catalogs, changelogs, and migration guidance.

Those details should not be invented before the interface exists. The future API and SDK remain planned. See Model Context Protocol for the separate open-protocol interface.