GhostAPI

GhostAPI lets you create REST API endpoints backed by Ghost Databases using natural language. Describe what the API should do, and Dymium generates the endpoint — including the SQL query, backend code, and documentation. APIs can be tested, refined, and deployed without writing code.

APIs are always created in the context of an Application, which defines the identity and authentication boundary for the endpoints it owns.

API Wizard

The API Wizard is the primary interface for creating GhostAPI endpoints. The workflow is:

1. Describe the API — Select a target Ghost Database, then enter a natural language prompt describing what the API should return. For example: "Return a list of customers with their email addresses and total order count." You can also view the database structure to understand available tables and columns.

2. Review the generated API — Dymium generates:
   - An HTTP method (GET or POST) and endpoint path
   - The target Ghost Database
   - A return type
   - Body parameters (for parameterized POST APIs)
   - OIDC parameters (fields extracted from the authentication token, if applicable)
   - A SQL query (expandable)
   - Generated backend code (expandable)
   - A human-readable description (expandable)

Most of these fields are editable — double-click to modify the method, endpoint name, return type, or parameters.

3. Refine — Send follow-up prompts to adjust the generated API, or edit fields directly and click Refine to apply pending changes.

4. Test — Click Test API to execute the API live and see real data returned from the Ghost Database. For POST APIs, fill in the required payload fields first. Testing is required before deployment.

5. Deploy — Click Deploy API (admins) or Submit for Approval (API Developer role). This opens the Assign API to Applications modal where you select which applications should have access to the API. Only applications with matching group membership to the target database are eligible.

API Developers cannot deploy directly — they submit APIs for admin approval. Admins can deploy immediately.

Assigning APIs to applications

Each API endpoint is assigned to one or more applications during deployment. This controls:

• Who can call the API — only applications the API is assigned to can invoke it
• How the API authenticates — inherited from the application (OIDC or Static API Key)
• MCP exposure — if the application has MCP enabled, the API automatically becomes an MCP tool for AI agents

Application assignments can also be edited after deployment from the View APIs page.

Consuming a deployed API

Once deployed, the API is called using the application's authentication credentials:

1. Obtain an OIDC token from the configured issuer (or use the static API key)
2. Call the endpoint with the token as a Bearer header

For OIDC applications, the user's identity propagates into the database layer. This means Row-Level Security (RLS) policies apply — the API returns only data the authenticated user is allowed to see.

Parameterized APIs

APIs can accept parameters, including parameters extracted automatically from OIDC tokens. For example, an API can be configured to filter results by the authenticated user's email address without the caller needing to pass it explicitly. This enables secure, identity-scoped data access.

Viewing deployed APIs

The View APIs page lists all deployed API endpoints. Each row shows the method, version, endpoint name, target database, return type, required payload fields, OIDC groups, and assigned applications. From here you can:

• Edit an API in the wizard
• View the SQL query, generated code, or description
• Copy a cURL command for any assigned application
• View version history and revert to an older version (admin only)
• Download the OpenAPI spec as JSON
• Edit assigned applications after deployment (admin only)
• Delete an API (admin only)

Applications tab

The Applications tab manages the applications that own and authenticate API endpoints. An application is a named identity and security boundary — it represents the machine, service, or agent that is calling the API.

Creating an application

Click Create New Application to configure:

• Application Name — a unique name used in URL paths and MCP endpoints.
• Authentication Type:
• OIDC (OpenID Connect) — clients present a JWT token from a trusted identity provider. One or more OIDC Issuer URLs must be configured. OIDC preserves user identity, supports group-based access, and enables Row-Level Security.
• Static API Key — a secret key is generated and used as a Bearer token. Simpler to set up, suitable for trusted internal services. The key is shown once after creation and cannot be retrieved later.
• Enable MCP for this application — when checked, an MCP server endpoint is created (see the MCP section below).

For OIDC applications, you can add multiple issuer URLs and click Use Portal Login Issuer to use the same issuer as portal logins. Issuers can be edited after creation via the Edit Auth column.

For Static API Key applications, the key can be regenerated from the table (the old key is invalidated immediately).

Store the API key securely when it is displayed. It cannot be retrieved later.

Applications table

The table shows all applications with their:

MCP (Model Context Protocol)

Applications can optionally expose their assigned GhostAPIs as MCP tools for AI agents. When MCP is enabled on an application, Dymium generates an MCP server that AI agent runtimes (such as Claude Desktop, Cursor, LangChain, or n8n) can connect to using the standard Model Context Protocol.

Each assigned GhostAPI automatically becomes a callable tool — the tool's name, description, and input schema are derived from the API definition. No separate tool configuration is required.

Enabling MCP — Toggle the MCP switch in the Applications table, or check Enable MCP for this application when creating a new application.

MCP server URL — When MCP is enabled, the endpoint is available at:

https://{tenant}.api.dymium.ai/mcp/{application_name}

You can view and copy this URL by clicking the info icon next to the MCP toggle.

Authentication — MCP requests use the same authentication as the application:

• OIDC — the agent presents a JWT Bearer token. The user's identity propagates through the entire stack (MCP → GhostAPI → Ghost Database → source), so Row-Level Security and data transformation policies are enforced even when an agent acts on a user's behalf.
• Static API Key — the agent presents the application's API key as a Bearer token.

Tool discovery and access control — When an agent connects, tool discovery returns all assigned GhostAPIs. For OIDC applications, the tool list is filtered by the user's group membership — agents only see tools they are authorized to use.

Tool invocation — Calling a tool executes the underlying GhostAPI with all Ghost Database policies (obfuscation, redaction) in effect.