Skip to main content

​
Ownership of Components by Organizations

Each component in the Kodexa platform is uniquely owned by a single organization. Components can be designated as “public”, permitting their utilization by other organizations.

​
Resource URIs

Components are identified by a resource URI that combines a scheme, the organization’s slug, and the component’s slug: 
scheme://org_slug/component_slug
For example: 
module://kodexa/pdf-parser
taxonomy://acme-corp/invoice-taxonomy
data-form://kodexa/spreading-form
Versions are no longer used in resource URIs. The platform resolves resources by organization and slug only. If a legacy URI includes a version suffix (e.g., module://kodexa/pdf-parser:1.0.0), the version is stripped automatically.

​
Resolver API

The platform provides a resolver endpoint that converts a resource URI into the concrete API path for that resource.

​
Resolving a Resource

POST /api/resolve?path=module://kodexa/pdf-parser
Response: 
{
  "uri": "module://kodexa/pdf-parser",
  "path": "/api/modules/abc-123-def-456"
}
The returned path is the ID-based API endpoint you can use for subsequent operations on that resource.

​
Discovering Available Schemes

GET /api/resolve/schemes
Returns the list of all supported resource schemes and their API endpoint patterns.

​
Resource Types

Kodexa supports the following resource types, each with a URI scheme and corresponding API path:
SchemeAliasesAPI PathScopeDescription
modulemodel, model-runtime/api/modulesOrgModules for parsing, transforming, and labeling documents
document-storestore/api/document-storesOrgRepositories for files and their document representations
data-store/api/data-storesOrgStructured data extracted from documents
taxonomydata-definition/api/data-definitionsOrgData structure definitions within Kodexa
project-template/api/project-templatesOrgBlueprints for creating new projects with predefined configurations
promptprompt-template/api/promptsOrgPrompt templates for LLM-based processing
data-form/api/data-formsOrgForm definitions for data entry and review interfaces
knowledge-set/api/knowledge-setsOrgCollections of knowledge items for reference and extraction
knowledge-item-type/api/knowledge-item-typesOrgType definitions for knowledge items
knowledge-feature-type/api/knowledge-feature-typesOrgType definitions for knowledge features
service-bridge/api/service-bridgesOrgBridge definitions for external service integrations
task-status/api/project-task-statusesProjectTask status definitions within a project
task-template/api/task-templatesProjectTask template blueprints within a project
assistant/api/assistantsProjectAssistant configurations within a project
Aliases resolve to the same underlying resource. For example, model://kodexa/invoice-extractor and module://kodexa/invoice-extractor both resolve via /api/modules.

​
Project-Scoped Resources

Most resource schemes are scoped to the organization. However, some resources (task-status, task-template, assistant) are scoped to a project within an organization. Their URIs use a three-part path: 
scheme://orgSlug/projectSlug/resourceSlug
For example: 
task-status://acme-corp/invoice-project/approved
task-template://acme-corp/invoice-project/document-review
assistant://acme-corp/invoice-project/pipeline-assistant
The resolver looks up the project by orgSlug/projectSlug and then finds the resource within that project by its slug.

​
Referencing Components

When referencing a component in YAML configuration files (such as project templates or assistant definitions), use the URI scheme format: 
# Module reference in a pipeline step
ref: module://kodexa/pdf-parser

# Taxonomy reference
ref: taxonomy://acme-corp/invoice-taxonomy

# Store reference in an assistant connection
sourceRef: "${orgSlug}/${project.id}-processing"
In contexts where the scheme is implicit (such as a taxonomies section that only accepts taxonomy references), you can use the short form: 
taxonomies:
  - ref: "acme-corp/invoice-taxonomy"

​
Projects and Entities

Projects amalgamate various components to address a specific use-case. Components capture metadata and are deployable, while entities store data or link to content. Typical entities include:
  • Projects
  • Documents
  • Data objects
  • Assistants
  • Executions
Entities each have a unique ID and are typically managed by a type of component or fall under the organization’s purview. This distinction is critical: components form part of the organizational configuration for a use-case, whereas entities are associated with the projects, data, or documents being worked on.