Integrations and API Keys

Pomavo can now represent automation as a real identity in your organization. Integrations and API Keys gives scripts, AI assistants, and external systems a safer way to act in Pomavo with attribution, permissions, and revocation.

Machine identities separate automation from people

Machine identities are non-human service accounts for programmatic access. Instead of sharing a personal login with a bot, webhook, build job, or AI assistant, you can create an integration that owns its own identity.

Each identity has a name, description, avatar, API keys, and an audit trail. When it comments, updates a ticket, downloads an attachment, or runs a query, Pomavo can attribute that action to the integration instead of a human teammate.

This is the right foundation for CI systems, import tools, internal scripts, AI agents through MCP, and future marketplace integrations.

API key authentication is built for non-interactive clients

API keys give automated clients a direct authentication method without browser sessions. A client sends the key with API requests, and Pomavo resolves the key to its integration identity and organization.

Keys are generated once. The plaintext value is shown at creation time, while Pomavo stores only a hash after that. If a key is lost, create a new one and revoke the old key rather than trying to recover it.

For AI and automation, the MCP server uses X-API-Key together with X-Org-Short-Name. That keeps the assistant pinned to one organization and makes every tool call permission-gated.

Permissions keep API access least privilege

An API key is not an admin bypass. It gives the client the same level of access as the integration's user identity, controlled through the fine-grained permission system.

This is important because the API covers tickets, templates, workflows, projects, iterations, comments, attachments, links, permissions, and query mutations. A narrowly scoped integration can read one project, comment on tickets, or download attachments without receiving unrelated organization powers.

Use Permissions to grant only the actions and resource scopes an integration requires. When the job changes, update the grants instead of sharing a broader key.

Integration avatars make automated activity legible

Custom avatar upload gives each integration a recognizable face in activity feeds, comments, and management lists. This matters once your organization has several automated actors, such as a GitHub connector, an import process, and an AI assistant.

The avatar is part of the identity. It helps users distinguish a machine update from a teammate update and makes audit trails easier to scan.

A good integration profile should include a clear name, a short description, and an avatar that users can recognize at a glance.

Template field defaults make created tickets more complete

Template field defaults let integrations and users create tickets with more reliable starting values. When a template defines defaults, new tickets can begin with the expected structure instead of requiring every client to send every field every time.

Defaults are especially helpful for automation. An incoming integration can create a ticket with the customer-provided fields while Pomavo fills in standard values such as priority, category, or workflow-related metadata configured by the template.

Template defaults do not remove validation. They make valid creation easier by giving the system a better initial field set.

Attachment download tooling closes the automation loop

Attachments are part of the API surface for integrations. With download tooling, automated clients can fetch files attached to tickets when they have the right permission.

This supports workflows such as AI summarization, build artifact inspection, customer evidence review, and data export. It also makes the MCP server more useful, because an assistant can work with ticket files through a governed tool instead of asking a person to copy data manually.

Organization deletion performs cascading cleanup

Organization deletion now includes cascading cleanup so removing a workspace can clean up associated data consistently. This matters for test tenants, expired trial workspaces, and organizations that need a complete removal path.

Because Pomavo is multi-tenant, organization data is scoped across tickets, templates, projects, members, permissions, integrations, API keys, and other related records. Cascading cleanup gives the product one deliberate path for that removal instead of leaving scattered records behind.

Use deletion carefully. For normal archival or migration, export and review organization data from Organization Settings before deleting the workspace.

API surface for integrations

The integration model is useful because the API covers the work Pomavo teams already do in the UI. Programmatic access is not a separate product area, it is the same ticketing system with the same security model.

Here is a query an integration could use before applying automation to a controlled set of tickets:

1
2
3

template = "Bug" and status in ("New", "Triaged") and priority in ("High", "Critical")
order by created_at asc
limit 25

The API key does not determine whether this query can read or mutate the matching tickets. The integration's permissions do.

A safer pattern for AI assistants and scripts

The biggest practical change is the operating pattern. Create one integration per external system, grant narrow permissions, create one or more named keys, store each key securely, and revoke keys when the client no longer needs them.