AI Enabler Built on Enterprise Data Models

DSiloed is the platform behind Portablemind: an AI enablement engine built on comprehensive enterprise data models, exposed through a REST API, WebSockets, and MCP tools.

This guide covers the developer surface of the platform — API integration and authentication, the MCP tools your agents can call, sandboxed Dynamic Functions, and building your own applications on the data foundation. For using the Portablemind app itself (chat, agents, files, sharing, orchestration), see the user guide.

DSiloed is built on a flexible, enterprise-grade data model designed for extensibility and integration. Here are the key components:

Model Context Protocol (MCP) tools provide a standardized interface for AI models to interact with your DSiloed platform. These tools enable LLMs to perform operations, access data, manage agents, handle communications, and more.

All MCP tools are available through the MCP server and can be used by external applications, AI agents, and LLM conversations. This reference lists all 35+ available MCP tools with their descriptions and use cases.

Tools are organized into categories for easier filtering and discovery. Use these category names with the categories query parameter to load specific tool groups.

Tools for sending emails and managing conversation invitations.

Tools for CRUD operations, schema discovery, and file management.

Tools for creating, managing, and executing autonomous AI agents.

Tools for persistent memory management across AI sessions.

Tools for managing LLM conversations and messaging.

Tools for accessing platform documentation.

Utility and administrative tools for system operations.

Tools for creating, managing, and executing serverless JavaScript functions.

web_research_tool — Search and fetch the public web (DuckDuckGo / Tavily / Brave / Wikipedia).

list_llm_tools_tool — List available custom LLM Tools with their status and configuration.

get_llm_tool_tool — Get details of a specific custom LLM Tool by ID or name.

manage_llm_tool_tool — Create, update, and delete custom LLM Tools.

test_llm_tool_tool — Test-execute a custom LLM Tool with provided parameters.

external_mappings_by_system_tool — Get external-system ID mappings for integrated systems (Master Data Management).

tail_rails_log_tool — Tail Rails logs for debugging (tenant-scoped access).

llm_cost_stats_tool — Get LLM cost and token-usage statistics.

create_workflow_artifact_tool — File an organized, work-item-linked structured-work artifact (any domain).

coordination_tool — Claim / release / inspect advisory leases on shared resources (e.g. the shared DEV/PROD environment).

MCP tools can be accessed in multiple ways:

DSiloed provides a comprehensive RESTful API for building applications. All endpoints follow consistent RESTful conventions with JSON responses.

Authentication

Authentication uses JWT (JSON Web Tokens) passed in the Authorization header.

curl -X GET "https://example-model-api.com/api/v1/parties" \
    -H "Authorization: Bearer YOUR_JWT_TOKEN" \
    -H "Tenant-Id: your-tenant-id"

Content Types

All API requests should use JSON for request bodies and accept JSON responses.

-H "Content-Type: application/json" \
-H "Accept: application/json"

Response Format

Responses follow a consistent format with data returned in an object named after the resource.

// Single resource example (e.g., GET /api/v1/users/123)
{
  "success": true,
  "user": {
    "id": 123,
    "description": "John Doe",
    "created_at": "2025-05-01T12:34:56Z",
    "updated_at": "2025-05-02T10:11:12Z"
  }
}

// Multiple resources example (e.g., GET /api/v1/users)
{
  "success": true,
  "total_count": 42,
  "users": [
    {
      "id": 123,
      "description": "John Doe",
      "created_at": "2025-05-01T12:34:56Z"
    },
    {
      "id": 124,
      "description": "Jane Smith",
      "created_at": "2025-05-02T08:15:30Z"
    }
    // ... more users
  ]
}

Error Handling

Errors return a simple format with success set to false and an error message.

{
  "success": false,
  "message": "Invalid Access"
}

Dynamic Functions provide a serverless JavaScript execution environment within the DSiloed platform. They allow you to create, manage, and execute custom JavaScript functions that can integrate with external APIs, process data, and automate workflows—all without managing any infrastructure.

Create a dynamic function using the REST API. Functions receive a context object with parameters, configuration, OAuth tokens, and tenant information.

// Create a function via REST API
POST /api/v1/dynamic_functions
Content-Type: application/json

{
  "dynamic_function": {
    "name": "hello_world",
    "description": "A simple greeting function",
    "javascript_code": "return { message: 'Hello, ' + (params.name || 'World') + '!' };",
    "active": true,
    "timeout_seconds": 30
  }
}

Execute the function by ID or name:

// Execute by name
POST /api/v1/dynamic_functions/hello_world/execute
Content-Type: application/json

{
  "params": {
    "name": "DSiloed"
  }
}

// Response:
{
  "success": true,
  "result": { "message": "Hello, DSiloed!" },
  "execution_id": 456,
  "execution_time_ms": 12
}

Functions receive a rich context with access to parameters, configuration, and built-in functions for data access and HTTP requests.

// Available context properties
params                    // Parameters passed when executing
config                    // Function configuration (excluding secrets)
functionId                // Database ID of this function
functionName              // Function name
tenantId                  // Current tenant ID

// OAuth tokens (if connected)
oauth.accessToken         // OAuth access token
oauth.tokenType           // Token type (usually "Bearer")

// Callback context (only in callback executions)
event                     // 'create', 'update', or 'destroy'
model_name                // Model class name (e.g., 'Task')
record_id                 // ID of the affected record
record                    // Full record data
changes                   // Changed attributes (update only)

// Make HTTP requests to external APIs
const response = await fetch('https://api.example.com/data', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${oauth.accessToken}`,
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({ key: 'value' })
});

const data = await response.json();
return { fetched: data };

// Query tenant data
var customers = executeAction('Individual', 'list', {
  filters: { role_type_id: 'customer' },
  limit: 100
});

// Create records
var newContact = executeAction('PhoneNumber', 'create', {
  attributes: {
    party_id: 123,
    phone_number: '555-1234'
  }
});

// Update records
executeAction('Individual', 'update', {
  id: 456,
  attributes: { custom_fields: { synced: true } }
});

// Convenience wrappers also available:
listRecords(modelName, options)
getRecord(modelName, id)
createRecord(modelName, attributes)
updateRecord(modelName, id, attributes)
deleteRecord(modelName, id)
findOrCreateRecord(modelName, findAttrs, createAttrs)

// Execute another DynamicFunction by name (synchronous by default)
const result = executeFunction('helper_function', { key: 'value' });

if (result.success) {
  console.log('Helper returned:', result.result);
} else {
  console.error('Helper failed:', result.error);
}

// Execute asynchronously (queued for background execution)
const asyncResult = executeFunction('long_running_task', { data: params.input }, true);
// Returns immediately: { success: true, message: '...', execution_id: ... }

// Chain multiple functions together
const validation = executeFunction('validate_data', { data: params.input });
if (!validation.success || !validation.result.valid) {
  return { success: false, error: 'Validation failed' };
}

const processed = executeFunction('process_data', {
  data: params.input,
  validationResult: validation.result
});

return processed.result;

// executeFunction(functionNameOrId, params, async)
// - functionNameOrId: Name or ID of the function
// - params: Parameters object (optional)
// - async: If true, queues for background execution (optional, default: false)

// Look up external ID for a local record
var result = getExternalId('Party', partyId, 'xero', 'xero_user_id');
if (result.found) {
  console.log('Xero user ID:', result.external_id);
}

// Find local record by external ID
var projectMapping = findByExternalId('Project', 'xero', xeroProjectId);
if (projectMapping.found) {
  var localProject = projectMapping.record;
}

// Store a new mapping
storeExternalMapping('Project', localProjectId, 'xero', xeroProjectId, {
  column_name: 'xero_project_id',
  table_name: 'xero_projects',
  is_primary_key: true
});

Functions can be scheduled to run automatically using cron expressions. The scheduler checks every 30 seconds for functions due to execute.

// Create a scheduled function
POST /api/v1/dynamic_functions
{
  "dynamic_function": {
    "name": "daily_sync",
    "description": "Sync contacts with CRM every morning",
    "javascript_code": "/* sync logic */",
    "schedule": "0 9 * * *",
    "timeout_seconds": 120,
    "run_as_user_id": 123,
    "active": true
  }
}

Functions can be triggered automatically when records are created, updated, or destroyed. This enables event-driven automation without polling.

// Create a callback function for task creation
POST /api/v1/dynamic_functions
{
  "dynamic_function": {
    "name": "on_task_created",
    "description": "Notify team when tasks are created",
    "callback_model": "Task",
    "callback_event": "create",
    "run_as_user_id": 123,
    "javascript_code": `
      // Context includes: event, model_name, record_id, record
      console.log('Task created:', record.name);

      // Send notification to external system
      await fetch('https://slack.com/api/chat.postMessage', {
        method: 'POST',
        headers: {
          'Authorization': 'Bearer ' + oauth.accessToken,
          'Content-Type': 'application/json'
        },
        body: JSON.stringify({
          channel: '#tasks',
          text: 'New task created: ' + record.name
        })
      });

      return { notified: true };
    `
  }
}

Dynamic Functions support OAuth 2.0 for integrating with external services. OAuth is configuration-based, meaning any OAuth 2.0 provider can be used without code changes.

OAuth Configuration

{
  "oauth": {
    "provider": "xero",
    "client_id": "YOUR_CLIENT_ID",
    "client_secret": "YOUR_CLIENT_SECRET",
    "authorize_url": "https://login.xero.com/identity/connect/authorize",
    "token_url": "https://identity.xero.com/connect/token",
    "scopes": ["openid", "profile", "accounting.transactions.read"]
  }
}

OAuth Flow

AI agents can manage and execute Dynamic Functions via five dedicated MCP tools. This enables intelligent automation where AI can create, modify, and run custom code.

DSiloed comes with several sample applications that demonstrate different capabilities of the platform. Each app is built as a static JavaScript application that interacts with the API.

An app built on PortableMind lives on its own origin (your domain, your hosting) and talks to the platform API from its own server. The browser talks to your server; your server holds the credentials and forwards authenticated requests to https://www.dsiloed.com/api/v1/.... Never ship a platform credential to the browser.

Signing in

Exchange a user's credentials for a session token with POST /api/v1/authenticate (email or username, plus password). A successful response carries the token as jwt; a user with multi-factor authentication gets an MFA challenge instead, which your app must complete.

curl -X POST "https://www.dsiloed.com/api/v1/authenticate" \
    -H "Content-Type: application/json" \
    -H "Tenant-Id: your-tenant-id" \
    -d '{"email": "user@example.com", "password": "..."}'

Send the token on every later call, together with the tenant header, exactly as described in API Documentation:

curl "https://www.dsiloed.com/api/v1/parties" \
    -H "Authorization: Bearer YOUR_JWT_TOKEN" \
    -H "Tenant-Id: your-tenant-id"

Request and response schemas for every public endpoint are in the interactive API reference.

Two complete open-source apps are published as public repos, each structured as a template you can fork. Both use the same minimal architecture: a single-page HTML + vanilla JavaScript frontend and a tiny zero-dependency Node proxy that injects runtime configuration and forwards authenticated requests to the platform. No framework, no build step.

Each repo's README and integration guide cover setup, the role files it ships and its deployment. The fastest path to a custom app is to hand one of them to a coding agent and describe what you want to build; see the developer resources page for a ready-made prompt.

Your app's security role is part of your app, not the platform. Build it once in a development workspace (Administration → Roles), export it (GET /api/v1/security_roles/:id/export or the Export button), keep the JSON file in your repo, and import it into each workspace on every release:

curl -X POST "https://www.dsiloed.com/api/v1/security_roles/import" \
    -H "Authorization: Bearer YOUR_JWT_TOKEN" \
    -H "Tenant-Id: your-tenant-id" \
    -H "Content-Type: application/json" \
    -d "$(jq -n --slurpfile d roles/my_role.json '{data: $d[0], overwrite: false}')"

• The import must be run by a workspace admin: an admin user's session, or an API key that itself holds the workspace's admin role. A plain API key is refused.
• It is exact and repeatable: the role is created if missing, then its capabilities are replaced by the file's. Run it on every release.
• Prefer scoped capabilities: an unscoped grant applies to every record of that kind in the workspace, not just your app's.
• Who holds the role is separate from the file. When your app server creates users at runtime with an ordinary (non-admin) API key, it can only assign roles marked external, plus the app section roles (app_chat, app_files, app_projects, app_tickets; never app_admin) when the same call also assigns an external role; any other internal role is assigned by an admin.

To drop your app's signed-in users into the full PortableMind web app under your branding, with no second login, a workspace admin enables white-label (PUT /api/v1/white_label) and mints a sign-on key (POST /api/v1/white_label/sso_key, shown once). Your server then signs a short-lived, single-use assertion (HS256, with sub, tenant_enterprise_identifier, jti, iat and an exp at most two minutes out) and redirects the browser to the web app's /sso?assertion=... route, which exchanges it through POST /api/v1/sso/exchange for an ordinary session.

Keep the sign-on key on your server: whoever holds it can sign in as anyone in the workspace. Setup is described in the user guide under White-label Branding & Single Sign-on.

Your app's end users (customers, clients, anyone outside the organization running the workspace) should be external members: they hold at least one role marked external. For them:

• an unscoped capability counts only when it comes from an external role;
• private records reach them only through ownership, an explicit share or membership;
• the built-in External Member role gives the personal basics the web app needs (notifications, preferences) and no business data.

Give such users External Member plus your app's own role, marked external, with every read scoped to the records they should see (for example, conversations they are a member of).

Now that you've explored the DSiloed platform, here are some next steps to continue your journey: