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:
For example:
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

Response:
The returned path is the ID-based API endpoint you can use for subsequent operations on that resource.

​
Discovering Available 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: 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) are scoped to a project within an organization. Their URIs use a three-part path:
For example:
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, use the URI scheme format:
In contexts where the scheme is implicit (such as a taxonomies section that only accepts taxonomy references), you can use the short form:

​
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
  • Activity runs
  • Tasks
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.