Connect Procurify to AI Agents: Automate Spend and AP Workflows

You want to connect Procurify to an AI agent so your system can autonomously draft purchase requisitions, approve vendors, reconcile accounts payable bills, and manage catalogs. Here is exactly how to do it using Truto's /tools endpoint and SDK, bypassing the need to build and maintain a custom Procurify integration from scratch.

Giving a Large Language Model (LLM) read and write access to your spend management platform is a high-stakes engineering challenge. You cannot afford for a model to hallucinate a purchase order number, incorrectly format a requisition payload, or overwrite a vendor's canonical record because it misunderstood a PUT request. If your team uses ChatGPT, check out our guide on connecting Procurify to ChatGPT, or if you are building on Anthropic's models, read our guide to connecting Procurify to Claude. For developers building custom autonomous workflows, you need a programmatic way to fetch these tools and bind them to your agent framework.

This guide breaks down exactly how to fetch AI-ready tools for Procurify, bind them natively to an LLM using frameworks like LangChain, LangGraph, CrewAI, or the Vercel AI SDK, and execute complex procurement workflows. For a deeper look at the architecture behind this approach, refer to our research on architecting AI agents and the SaaS integration bottleneck.

The Engineering Reality of the Procurify API

Building an AI agent is fundamentally an exercise in state management and prompting. Giving that agent reliable access to external systems is where most projects stall. If you decide to build a custom Procurify connector, you own the entire API lifecycle. You must write the JSON schemas for the LLM to understand the endpoints, handle the OAuth token lifecycle, normalize pagination, and deal with complex procurement data models.

The Procurify API introduces several specific integration challenges that break standard REST assumptions. If you hardcode these interactions into your agent, you will spend your sprints writing defensive integration code instead of improving your model's reasoning capabilities.

The PUT vs PATCH Overwrite Trap

When an agent wants to update a record - say, a vendor's legal name or a department's active status - LLMs naturally gravitate toward sending only the fields they want to change. Procurify exposes specific update methods via full PUT requests, and distinct partial_update methods via PATCH requests.

If your agent calls an update_a_procurify_location_by_id tool (which maps to a PUT request) and only provides the location name, Procurify will overwrite and nullify omitted fields like the currency, primary billing address, and phone numbers. Your agent will inadvertently wipe out critical business data. A unified tool layer enforces the schema, providing explicit tools like procurify_vendors_partial_update to ensure agents only execute safe, delta-based changes when needed.

Fragmented Lifecycle States

Procurement is not a simple CRUD operation. A single purchase request traverses multiple distinct state models. An agent cannot simply "create a purchase order." It must create a Requisition (with required dates, locations, and line items). That requisition must be approved, converted to an Order, and eventually tied to a Purchase Order, which is then fulfilled via Receipt Items.

Exposing the raw Procurify API to an LLM requires the model to hold this entire state machine in its context window. It has to know that receiving goods requires creating a receipt_item linked to an order_item, passing the exact pass_quantity and fail_quantity. A unified toolset abstracts these states into discrete, well-defined functions, dramatically shrinking the attack surface for hallucination.

Strict UUID and ID Enforcement

Procurify uses a mix of integer IDs and UUIDs across different objects. For example, getting a purchase order by ID uses an integer, while querying accounts payable bills requires a canonical UUID. LLMs are notoriously bad at differentiating between ID types. If you feed the LLM a raw endpoint, it will frequently attempt to pass a string UUID into an integer ID path parameter, causing a 400 Bad Request error. Truto's proxy APIs strictly type these inputs in the JSON schema, rejecting invalid ID formats before the network request ever leaves your server.

Hero Tools for Procurify Automation

A unified tool layer collapses Procurify's complex data model into a stable schema. Your agent sees deterministic function names with strict input validation.

Here are six high-leverage tools available for Procurify that enable true autonomous spend management.

Create a Requisition

This tool initiates the procurement lifecycle. It allows the agent to draft a purchase request with specific line items, location constraints, and department allocations. Because the schema enforces the nested line_items array, the agent cannot submit a malformed request.

"Draft a new requisition for the Engineering department at the San Francisco location for 15 new developer laptops needed by next Friday."

Get a Purchase Order by ID

Agents frequently need to investigate the status of an ongoing order. This tool retrieves a specific purchase order along with its associated items, surfacing states like 'purchased', 'cancelled', 'closed', or 'paid'.

"Check the status of purchase order PO-8842 and tell me if the items have been received yet."

Create a Receipt Item

When physical goods or services arrive, the system needs to log them. This tool allows the agent to receive order items within a single purchase order, explicitly splitting the pass_quantity (accepted goods) and fail_quantity (damaged or rejected goods).

"Log the receipt of order item 49210. 10 monitors arrived in good condition, but 2 arrived with cracked screens and failed inspection."

Mark Bills as Paid

For Accounts Payable (AP) automation, agents need to close out approved bills once funds have cleared. This tool takes an array of bill UUIDs and a payment date, marking them as settled in Procurify's ledger.

"Find the approved bills for vendor TechCorp and mark them as paid using today's date."

Partially Update a Vendor

Vendor details change frequently. This tool executes a safe PATCH request, ensuring that the agent only updates the specified fields (like a new billing address or active status) without risking the deletion of other vital vendor metadata via a full PUT overwrite.

"Update the vendor record for 'CloudHosting Inc.' to change their active status to false, they are no longer an approved supplier."

List Global Order Items

This read-heavy tool allows the agent to audit open order items across the entire organization. It supports filtering by purchase order or receiving status, making it the perfect tool for generating daily procurement digest reports.

"Pull a list of all pending order items across the organization that have not yet been received."

For the complete inventory of available tools, including detailed query schemas, required parameters, and object structures, view the Procurify integration page.

Workflows in Action

Individual tools are useful, but the real power of an AI agent emerges when it chains these tools together to solve multi-step problems autonomously. Here are three real-world workflows you can build using the Procurify toolset.

Workflow 1: Autonomous AP Invoice Reconciliation

Accounts Payable teams spend hours matching vendor invoices against approved purchase orders and receiving logs. An AI agent can automate this three-way matching process entirely.

"We just received an invoice from 'OfficeSupplies Co'. Check our recent bills, verify if the items were received successfully, and if they were, mark the bill as paid."

1. list_all_procurify_bills: The agent searches for pending bills associated with the vendor 'OfficeSupplies Co'.
2. list_all_procurify_ap_items: It fetches the specific AP items linked to that bill to find the underlying order item IDs.
3. list_all_procurify_receipt_items: The agent checks if those order items have a logged receipt with a matching pass_quantity.
4. create_a_procurify_bill_paid_marking: Upon successful verification of the three-way match, the agent submits the bill UUIDs and payment date to close out the invoice.

Result: The agent successfully transitions the liability to a paid state without human intervention, maintaining a perfect audit trail.

Workflow 2: Vendor Onboarding and Compliance

When a new supplier is approved in an external system (like a GRC or contract management platform), the agent can automatically provision them in Procurify and establish their payment rails.

"Onboard 'Acme Logistics' as a new regular vendor. Set up their primary location data and attach their ACH payment method."

1. create_a_procurify_vendor: The agent creates the core vendor record, defining the type as 'regular' and passing the overall score and email.
2. create_a_procurify_vendor_payment_method: Using the ID from the previous step, the agent attaches an ACH payment method (type 2) using the provided routing and account data.

Result: A fully provisioned vendor record ready to accept requisitions, eliminating manual data entry by the procurement team.

Workflow 3: PO Exception Handling

Sometimes a purchase order is closed prematurely, but late invoices or delayed shipments arrive weeks later. An agent can investigate and rectify this state programmatically.

"PO number 9931 was closed, but the supplier just notified us that the final backordered item shipped. Reopen the PO so we can receive it."

1. get_single_procurify_purchase_order_by_id: The agent fetches the PO to confirm its current state is actually closed (state 3).
2. create_a_procurify_purchase_order_reopening: The agent issues the reopening command using the PO's unique ID.
3. list_all_procurify_order_items: The agent queries the items on that PO to verify the backordered line item is now available for receiving.

Result: The agent unblocks the receiving dock and AP team by resetting the state machine based on external supplier signals.

Building Multi-Step Workflows

To execute these workflows in production, your code needs to fetch the tool definitions from Truto, bind them to an LLM, and manage the execution loop. This approach is entirely framework-agnostic. Whether you use LangChain, LangGraph, CrewAI, or the Vercel AI SDK, the core architecture remains the same.

Below is a conceptual architecture of how the agent interacts with Truto and Procurify.

sequenceDiagram
    participant App as Your Application
    participant Agent as AI Agent (LLM)
    participant Truto as Truto /tools API
    participant Upstream as Upstream API (Procurify)

    App ->> Truto: GET /integrated-account/<id>/tools
    Truto -->> App: Return array of JSON Schema tools
    App ->> Agent: .bindTools(procurifyTools)
    App ->> Agent: User Prompt: "Draft a requisition..."
    Agent -->> App: Tool Call Request (create_a_procurify_requisition)
    App ->> Truto: Execute Proxy API call with args
    Truto ->> Upstream: Authenticated request to Procurify
    Upstream -->> Truto: 201 Created (UUID)
    Truto -->> App: Return normalized response
    App ->> Agent: Provide tool observation
    Agent -->> App: Final natural language response

Implementation with LangChain.js

Truto provides all the resources defined on an integration as tools for your LLM frameworks. Using the @trutohq/truto-langchainjs-toolset package, you can abstract away the manual fetching of the schemas.

import { ChatOpenAI } from "@langchain/openai";
import { TrutoToolManager } from "@trutohq/truto-langchainjs-toolset";
import { AgentExecutor, createOpenAIToolsAgent } from "langchain/agents";
import { ChatPromptTemplate } from "@langchain/core/prompts";
 
// 1. Initialize the LLM
const llm = new ChatOpenAI({
  modelName: "gpt-4o",
  temperature: 0,
});
 
// 2. Initialize the Truto Tool Manager for the specific Procurify account
const trutoToolManager = new TrutoToolManager({
  trutoToken: process.env.TRUTO.TRUTO_TOKEN,
  integratedAccountId: "procurify_account_12345",
});
 
async function runProcurementAgent() {
  // 3. Fetch all available Procurify tools dynamically
  const tools = await trutoToolManager.getTools();
 
  // 4. Create the prompt and bind tools
  const prompt = ChatPromptTemplate.fromMessages([
    ["system", "You are an elite procurement assistant. Execute actions in Procurify strictly using the provided tools."],
    ["placeholder", "{chat_history}"],
    ["human", "{input}"],
    ["placeholder", "{agent_scratchpad}"],
  ]);
 
  const agent = await createOpenAIToolsAgent({
    llm,
    tools,
    prompt,
  });
 
  const agentExecutor = new AgentExecutor({
    agent,
    tools,
    maxIterations: 5,
  });
 
  // 5. Execute the multi-step workflow
  const result = await agentExecutor.invoke({
    input: "Check the status of purchase order PO-8842 and tell me if the items have been received yet."
  });
 
  console.log(result.output);
}
 
runProcurementAgent().catch(console.error);

Handling Rate Limits and Errors

When building autonomous agents, error handling is critical. If your agent executes a loop that triggers a burst of API calls to Procurify, you may encounter HTTP 429 Too Many Requests errors.

It is a critical factual requirement to understand how Truto handles rate limits: Truto does not retry, throttle, or apply backoff on rate limit errors. When the upstream API (Procurify) returns an HTTP 429, Truto passes that error directly to the caller.

However, Truto normalizes upstream rate limit information into standardized headers per the IETF specification. Regardless of how the underlying vendor formats their limits, your application will receive:

• ratelimit-limit: The maximum number of requests allowed in the current window.
• ratelimit-remaining: The number of requests remaining in the current window.
• ratelimit-reset: The time at which the rate limit window resets.

The caller (your agent framework or application logic) is entirely responsible for reading these headers, implementing retry logic, and managing exponential backoff.

If you are building a custom tool executor (bypassing the standard SDK), your error handling should look like this:

async function executeProcurifyTool(url: string, args: any) {
  try {
    const response = await fetch(url, {
      method: 'POST',
      headers: { 
        'Authorization': `Bearer ${TRUTO_TOKEN}`,
        'Content-Type': 'application/json'
      },
      body: JSON.stringify(args)
    });
 
    if (response.status === 429) {
      // Extract standardized IETF headers provided by Truto
      const resetTime = response.headers.get('ratelimit-reset');
      const remaining = response.headers.get('ratelimit-remaining');
      
      console.warn(`Rate limit hit. 0 of ${remaining} remaining. Backing off until ${resetTime}.`);
      
      // Instruct the agent to wait, or implement your own queue/backoff logic here.
      throw new Error(`Rate limit exceeded. Pause execution until ${resetTime}`);
    }
 
    if (!response.ok) {
      throw new Error(`Upstream error: ${response.statusText}`);
    }
 
    return await response.json();
  } catch (error) {
    // Return the error to the LLM as an observation so it can self-correct
    return JSON.stringify({ error: error.message });
  }
}

By passing the error string back to the LLM as a tool observation, the agent can actively reason about the failure. If it provided a malformed UUID, it will see the 400 Bad Request error, realize its mistake, and attempt the tool call again with the correct identifier format.

Unblocking Spend Automation

Connecting Procurify to AI agents transforms procurement from a manual data-entry bottleneck into an autonomous, self-healing system. By leveraging a unified tool API, you protect your models from integration-specific quirks, enforce strict data schemas, and drastically reduce your engineering overhead.

Instead of reading vendor API docs and writing custom connector code, your engineers can focus on crafting better agent prompts and optimizing business logic.