Prapii

Connect AI agents to Prapii, the platform for building, securing, and exposing AI-powered APIs. Agents call an organization's own governed AI endpoints as a step in a flow.

3 actions API key available

Prapii website ↗ Platform Documentation ↗ Capability data verified 2026-08-01

A vendor emails a remittance advice PDF to the shared AP mailbox

Get Current Identity confirms the key points at the production project

Call AI API With File sends the document to the approved extraction API

Agent reads the returned JSON payload for invoice numbers and amounts

Agent inspects the response for sensitive data the project's policies caught

The AP reviewer is told which fields were flagged and by which policy

Reviewer decides whether the flagged output may move downstream

What This Integration Enables

Three actions. That is not a gap in the connector, it is the shape of the product. Prapii's argument is that prompts, context injection, model choice, token compression and sensitive-data policy should live in one governed place and be published as a named API, so that everything downstream just calls it. If that argument is right, the integration surface should be small on purpose, and it is: invoke an API by name, invoke it with a file attached, and confirm which organization and project your key resolves to.

What this buys an operations team is an approved endpoint rather than a scattering of prompts. A flow does not decide which model to use, what context to inject, or which fields must never be sent onward, because those decisions were made once in the Prapii console by the people accountable for them. The flow supplies a prompt and gets back an envelope: the answer, any JSON the API extracted, a conversation ID for keeping context across turns, tool call results, and the sensitive-data exposures the project's policies detected. That last field is the interesting one. It means the call does not merely apply a rule, it reports what the rule caught, which is the raw material of a real Code of Conduct rather than a policy nobody can audit. Self-hosting is supported for organizations that need the endpoint inside their own boundary. These operations are built and verified against the vendor's official API.

Without FlowRunner

Every flow carries its own prompt The same extraction is written three ways in three places and drifts

No record of what left the building Nobody can say which documents were sent to a model, or what came back

Policy lives in a review document The rule exists in writing and is enforced by whoever remembers it

With FlowRunner

Flows call a named approved API One definition, maintained in one console, invoked from wherever it is needed

Every response reports its exposures The call returns the sensitive data its own policies caught, on the same response

Policy is enforced at the endpoint Context injection and data policies run server-side rather than per flow

Use Case Scenarios

Document intake through the endpoint finance approved

Remittance advice arrives as a PDF in the shared AP mailbox monitored through Gmail. The flow calls Get Current Identity first, purely to confirm the access key resolves to the production project rather than a sandbox someone was testing in last week. It then calls Call AI API With File, which downloads the attachment and forwards it to the extraction API defined in the Prapii project. The response comes back with the structured payment lines as extracted JSON, and the flow writes them into Acumatica. The prompt that read the document is not in the flow, so improving extraction accuracy is a change in one console rather than a change across every intake flow that touches a vendor document.

Multi-turn context that stays inside one case

A support agent handles a customer thread in Zendesk. Each turn calls Call AI API and passes back the conversation ID returned by the previous call, so the API keeps the shared context of the case without the flow re-sending the whole history on every turn. That is efficient, and it is also a boundary that must not be crossed: a conversation ID is the thing that carries one customer's material forward, so the flow derives it from the ticket ID and never reuses one across tickets. Where a flow handles several cases in a batch, that mapping is the first thing to test.

One definition, many callers

Several unrelated flows need the same classification: intake from the web form, escalation triage inside the helpdesk, and a nightly sweep of anything that arrived by other routes. Each calls the same named Prapii API. When the classification taxonomy changes, one API definition changes and all three flows follow, because none of them owns the prompt. Get Current Identity gives each flow a cheap environment guard at the top, so a key rotated into the wrong project fails on a read rather than silently running production traffic against a staging configuration. This is what connectors are for in an Orchestration as a Service model: the flow coordinates, the governed endpoint decides.

Human-in-Loop Highlight

The gate here is written into the response. Every Prapii call returns the sensitive-data exposures its own policies detected, which means the connector hands the flow an explicit statement that something in this exchange touched material the organization has rules about. An agent that reads the answer and ignores that field is worse than an agent with no policy at all, because the organization now believes it has a control. So when the exposure list comes back non-empty on a document the flow is about to forward, the agent stops before the forward. It posts to the reviewer in Slack with the API that was called, the field the policy matched, and what the next step would have done, and asks: "The extraction on invoice 88214 returned a bank account number flagged by the payment-data policy. Forward the redacted payload to the ERP, forward it in full, or hold this document for manual entry?" The flow resumes on the answer. Nothing about that is a delay tactic; it is the digital andon cord, pulled by the one component in the chain that actually knows a rule was triggered.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via Slack

Human decides

Agent resumes with decision

Agent Capabilities

3 actions

AI API Calls

Call AI API Invokes an AI-powered API you have defined in your Prapii project by name, sending a user prompt and returning the AI response together with any extracted JSON, tool calls and sensitive-data exposures. Pass the same Conversation ID across calls to keep shared context between turns. Prapii applies your project's context injection, policies and token compression automatically.
Call AI API With File Invokes a Prapii AI API as a multipart request with a file attached, for multi-modal processing of Office documents, PDFs and images. The file is downloaded from the supplied URL and forwarded to Prapii together with the prompt. Use this instead of Call AI API whenever the API needs to read an uploaded document rather than a URL.

Account

Get Current Identity Returns the organization and project associated with the configured project access key. Use it to verify that a key is valid and points at the environment you expect before running other actions.

Frequently Asked Questions

What can FlowRunner do with Prapii?

FlowRunner agents can run Call AI API, Call AI API With File, and Get Current Identity in Prapii.

Does connecting Prapii to FlowRunner require OAuth?

No. Prapii connects to FlowRunner with an API key, no OAuth flow required.

Can Prapii trigger a FlowRunner workflow automatically?

Prapii doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Prapii

$100 in credits. No card required. Connect in minutes.

Start Building Free Talk to us