Connect Procurify to Claude: Sync Purchase Orders and Catalogs

If you need to connect Procurify to Claude to automate purchase order approvals, sync vendor catalogs, or reconcile accounts payable bills, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's tool calls and Procurify's REST APIs. You can either build and maintain this infrastructure yourself, or use a managed integration platform like Truto to dynamically generate a secure, authenticated MCP server URL.

If your team uses ChatGPT, check out our guide on connecting Procurify to ChatGPT or explore our broader architectural overview on connecting Procurify to AI Agents.

Giving a Large Language Model (LLM) read and write access to a sprawling procurement and spend management platform like Procurify is an engineering challenge. You have to handle API token lifecycles, map massive JSON schemas to MCP tool definitions, and deal with Procurify's specific relational data structures. Every time Procurify updates an endpoint or changes a required field, you have to update your server code, redeploy, and test the integration.

This guide breaks down exactly how to use Truto to generate a secure, managed MCP server for Procurify, connect it natively to Claude Desktop, and execute complex procurement workflows using natural language.

The Engineering Reality of the Procurify API

A custom MCP server is a self-hosted integration layer. While the open MCP standard provides a predictable way for models to discover tools, the reality of implementing it against specialized B2B APIs is painful. Procurify is built to manage complex purchasing hierarchies, strict approval routing, and granular chart-of-accounts tracking. Its API reflects that complexity.

If you decide to build a custom Procurify MCP server, here are the specific integration challenges you will face:

Deeply Nested Relational States Procurement in Procurify is not a flat object. A purchase lifecycle moves from Requisition (request) to Global Order (organization-wide tracking) to Purchase Order (vendor-facing document) to Receipt Item (receiving goods) to Bill (accounts payable). An LLM has no context on how these entities relate. If a user asks Claude to "mark the laptops as received," the LLM must know to query the specific order item, map it to a purchase order, and execute a POST request to create a receipt_item with specific pass_quantity and fail_quantity integers.

Rigid Full-Replacement PUT Constraints Procurify relies heavily on PUT requests for record updates rather than partial PATCH requests for many of its core entities. For example, if you want to update a location's phone number via the API, omitting the shipping_addresses array in your PUT payload will cause Procurify to overwrite or deactivate the existing shipping addresses. An LLM must be strictly guided by JSON schemas to fetch the full record first, modify the target field, and push the entire payload back.

Custom Field ID Resolution Procurify allows organizations to define custom fields on order items and bills. However, the API requires the canonical custom_field ID, not the human-readable string name. If an LLM tries to update an order item with {"Project Code": "Alpha"}, the API will reject it. The MCP server must expose a tool to list custom fields, allowing the model to look up the ID mapping before executing the update.

Creating the Procurify MCP Server

Instead of hardcoding tool definitions and manually handling Procurify's authentication, Truto dynamically generates an MCP server from the integration's resource definitions and documentation records.

A Truto MCP server is scoped to a single integrated account (a connected Procurify tenant). The server URL contains a cryptographically hashed token that encodes which account to use and what tools to expose.

You can create this MCP server in two ways.

Method 1: Via the Truto UI

This is the fastest method for internal tooling or quick prototyping with Claude Desktop.

1. Navigate to the Integrated Accounts page in your Truto dashboard and select your connected Procurify instance.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Configure the server. You can limit the server to specific operations (e.g., selecting only read methods to prevent Claude from accidentally creating purchase orders) or filter by tags (e.g., ["procurement", "ap"]).
5. Copy the generated MCP server URL. It will look like https://api.truto.one/mcp/a1b2c3d4...

Method 2: Via the API

For production use cases where you are programmatically provisioning AI agents for your end-users, you can generate MCP servers via the Truto REST API.

The API validates that the integration has documented tools available, generates a secure HMAC-signed token, stores it in Cloudflare KV for low-latency lookups, and returns a ready-to-use URL.

curl -X POST https://api.truto.one/integrated-account/<procurify_account_id>/mcp \
  -H "Authorization: Bearer <YOUR_TRUTO_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Procurify AP Automation Agent",
    "config": {
      "methods": ["read", "write"],
      "tags": ["purchase_orders", "bills", "vendors"]
    },
    "expires_at": "2026-12-31T23:59:59Z"
  }'

The response will contain the authenticated URL your agent needs:

{
  "id": "mcp_abc123",
  "name": "Procurify AP Automation Agent",
  "config": { 
    "methods": ["read", "write"],
    "tags": ["purchase_orders", "bills", "vendors"]
  },
  "expires_at": "2026-12-31T23:59:59.000Z",
  "url": "https://api.truto.one/mcp/a1b2c3d4e5f67890"
}

Connecting the MCP Server to Claude

Once you have the Truto MCP URL, connecting it to Claude requires zero additional coding. The URL alone contains the routing and authentication context needed to serve the JSON-RPC 2.0 protocol.

Method A: Via the Claude UI (or ChatGPT)

If you are using the web interfaces that support custom connectors:

1. Open Claude and navigate to Settings -> Integrations -> Add MCP Server (For ChatGPT, this is under Settings -> Apps -> Advanced settings -> Developer mode).
2. Name the integration (e.g., "Procurify").
3. Paste the Truto MCP URL.
4. Click Add or Save.

Claude will perform the MCP initialize handshake, request the tools/list, and immediately populate the available Procurify operations based on the filters you set during creation.

Method B: Via Manual Config File (Claude Desktop)

If you are running Claude Desktop locally and prefer file-based configuration, you can update your claude_desktop_config.json file. Because Truto provides a remote HTTP endpoint rather than a local standard IO script, you bridge the connection using the official @modelcontextprotocol/server-sse package.

Open your config file:

• Mac: ~/Library/Application Support/Claude/claude_desktop_config.json
• Windows: %APPDATA%\Claude\claude_desktop_config.json

Add the Procurify server configuration:

{
  "mcpServers": {
    "procurify": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-sse",
        "https://api.truto.one/mcp/a1b2c3d4e5f67890"
      ]
    }
  }
}

Restart Claude Desktop. You will now see the "hammer" icon indicating the tools are loaded and ready for natural language invocation.

Hero Tools for Procurify

Truto automatically translates Procurify's API documentation into LLM-friendly schemas. When a tool is called, the MCP router splits Claude's flat argument object into query parameters and body parameters based on these generated JSON schemas, delegating the execution to the underlying proxy API handlers.

Here are the most critical, high-leverage tools available in the Procurify MCP server.

create_a_procurify_requisition

Creates a new purchase request (requisition) with associated line items. This is the entry point for spend in Procurify. The LLM must supply an array of line_items along with location and department names.

"I need to order 5 new Dell XPS 15 laptops for the engineering team in the New York office. Create a requisition for this. The vendor is Dell and the estimated price is $2,000 each. Put it under the Software Engineering department."

list_all_procurify_purchase_orders

Searches and lists purchase orders based on a specific role (purchased or receivable) and status. This tool is vital for agents acting as procurement managers looking to track order progress.

"Show me all the purchase orders that are currently in 'purchased' status but haven't been fully received yet. I need to follow up on outstanding IT equipment deliveries."

update_a_procurify_purchase_order_by_id

Updates a purchase order by its internal Procurify PO number. Because Procurify requires full updates for PUT endpoints, the schema explicitly instructs the LLM to provide the complete buyer and receiver contact information, promise dates, and line items.

"Update purchase order PO-2026-049. Change the promise date to next Friday, and update the receiver contact name to 'Jane Doe'. Make sure to include all existing line items and address details so nothing gets overwritten."

create_a_procurify_receipt_item

Logs a receiving action against a specific order item. This tool is used to track when goods physically arrive. It requires specifying the pass_quantity (accepted goods) and fail_quantity (rejected/damaged goods).

"The shipment for the office chairs just arrived. The order item ID is 8492. We received 10 chairs in perfect condition, but 2 of them were damaged. Log the receipt item reflecting this pass and fail quantity."

list_all_procurify_bills

Lists accounts payable bills, filterable by status, dates, vendor, and export state. Crucial for AP automation agents attempting to reconcile invoices against received purchase orders.

"Find all accounts payable bills for 'AWS' from the last 30 days that are currently in an 'approved' status but haven't been exported to our accounting system yet."

create_a_procurify_bill_paid_marking

Marks an approved bill that has no recorded payment as paid, attaching a specific payment date. This is the final step in closing the AP loop within Procurify.

"I just paid the outstanding invoices for Microsoft via wire transfer today. Mark the bills with UUIDs 3f9a-4b2c and 8d1e-9f3a as paid, using today's date as the payment date."

To view the complete inventory of available tools, required schema parameters, and entity relationships, visit the Procurify integration page.

Workflows in Action

MCP tools become powerful when Claude chains them together to accomplish multi-step workflows. Because the LLM maintains context across tool calls, it can handle the sequential ID mapping required by Procurify's relational architecture.

Workflow 1: Purchase Order Fulfillment & Receiving

Persona: Procurement Manager
Goal: Find a specific PO, identify its line items, and mark them as fully received.

"Check on purchase order PO-5921. If it's still unreceived, mark all the items on it as fully received in perfect condition."

Execution Steps:

1. Claude calls list_all_procurify_purchase_orders or get_single_procurify_purchase_order_by_id using the PO number to retrieve the order details.
2. The API returns the PO object, which includes an array of items and their respective ids.
3. Claude parses the quantities for each item.
4. Claude loops through the items and calls create_a_procurify_receipt_item for each one, setting pass_quantity to the total ordered amount and fail_quantity to 0.

Result: The user gets a confirmation message that the items were successfully received, and the PO status in Procurify automatically updates to "Received".

sequenceDiagram
    participant User
    participant Claude as "Claude Desktop"
    participant Truto as "Truto MCP Router"
    participant Procurify as "Procurify API"

    User->>Claude: "Receive all items for PO-5921"
    Claude->>Truto: call tool get_single_procurify_purchase_order_by_id(id: "PO-5921")
    Truto->>Procurify: GET /api/v3/purchase-orders/PO-5921
    Procurify-->>Truto: { uuid, items: [ {id: 101, qty: 5}, {id: 102, qty: 2} ] }
    Truto-->>Claude: JSON result
    Claude->>Truto: call tool create_a_procurify_receipt_item(order_item: 101, pass: 5, fail: 0)
    Truto->>Procurify: POST /api/v3/receipts
    Procurify-->>Truto: 201 Created
    Truto-->>Claude: Success
    Claude->>Truto: call tool create_a_procurify_receipt_item(order_item: 102, pass: 2, fail: 0)
    Truto->>Procurify: POST /api/v3/receipts
    Procurify-->>Truto: 201 Created
    Truto-->>Claude: Success
    Claude-->>User: "All items for PO-5921 have been marked as received."

Workflow 2: AP Automation & Bill Reconciliation

Persona: Accounts Payable Specialist
Goal: Identify approved but unpaid bills for a specific vendor and mark them as paid.

"Find all approved but unpaid bills for 'Salesforce' from this month. If there are any, mark them as paid today."

Execution Steps:

1. Claude calls list_all_procurify_bills with filters for the vendor name and status.
2. The API returns a list of bill objects, including their uuids.
3. Claude extracts the UUIDs of the matching bills.
4. Claude calls create_a_procurify_bill_paid_marking passing the array of bill_uuids and today's date as the payment_date.

Result: The LLM bypasses the need for the user to manually hunt through the Procurify AP dashboard, automatically reconciling the ledger state in seconds.

Handling Rate Limits in Production

When deploying AI agents that make rapid, chained API requests, you will inevitably encounter API rate limits. Procurify enforces specific quotas on its endpoints to maintain stability.

Factual note on rate limits: Truto does not retry, throttle, or apply backoff on rate limit errors automatically. When the upstream Procurify API returns an HTTP 429 Too Many Requests, Truto passes that error directly back to the caller. Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF specification.

The caller (your agent framework or Claude client) is responsible for intercepting the 429 error, reading the ratelimit-reset header, and implementing its own retry/backoff logic.

Security and Access Control

Exposing an ERP or procurement system to an LLM requires strict governance. Truto provides several mechanisms on the mcp_token to restrict what an AI agent can do with Procurify data.

• Method Filtering: By defining config.methods: ["read"], the MCP router will only generate tools for GET and LIST endpoints. If the agent attempts to hallucinate a write operation, the tool simply will not exist in the server's capabilities.
• Tag Filtering: Integration resources in Truto are tagged (e.g., "ap", "procurement", "directory"). You can restrict an MCP server via config.tags so that it only exposes tools related to Accounts Payable, hiding sensitive HR or system admin endpoints.
• Require API Token Auth: By setting require_api_token_auth: true, possession of the MCP URL is no longer sufficient. The MCP client must also pass a valid Truto API token in the Authorization header, ensuring that only authenticated internal services can execute the tools.
• Time-to-Live (TTL): You can pass an expires_at ISO datetime when creating the MCP server. Cloudflare KV will automatically evict the token, and a Durable Object alarm will purge the database record, completely terminating access for temporary agents or contractors.

Building Agentic Workflows for Procurement

Connecting Procurify to Claude via a managed MCP server transforms how teams interact with procurement data. Instead of building custom scripts to parse vendor catalogs, manage complex requisition states, or reconcile AP bills, you can expose the raw API capabilities to an LLM safely and reliably.

By leveraging Truto's dynamic tool generation, you bypass the manual labor of maintaining JSON schemas and managing token lifecycles, allowing your engineering team to focus on the agent's core prompts rather than the integration plumbing.