Connect Wiwink to Claude: Sync Works, Installers & Product Inventory

If you need to connect Wiwink to Claude to automate work orders, dispatch installers, or sync product inventory, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's natural language tool calls and Wiwink's REST APIs. You can either spend weeks building and maintaining 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 Wiwink to ChatGPT or explore our broader architectural overview on connecting Wiwink to AI Agents.

Giving a Large Language Model (LLM) read and write access to a sprawling enterprise resource planning tool like Wiwink is a serious engineering challenge. You have to handle complex relational endpoints, map massive JSON schemas to MCP tool definitions, and deal with Wiwink's specific data structures. Every time an endpoint changes or you add a new custom 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 Wiwink, connect it natively to Claude Desktop, and execute complex field service workflows using natural language.

The Engineering Reality of the Wiwink 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 vendor APIs is painful. You are not just integrating a simple database - you are integrating an operational platform with rigid state machines, strict relational dependencies, and complex data models.

If you decide to build a custom MCP server for Wiwink, you own the entire API lifecycle. Here are the specific challenges you will face with the Wiwink API:

Sideloading and Sparse Fieldsets Wiwink relies heavily on a with [] array pattern for sideloading relational data. For example, when fetching works, you must explicitly pass with []=customer or with []=status to get the related entities rather than just IDs. LLMs struggle immensely with formatting array-based query parameters consistently from scratch. If you expose the raw API to Claude, it will frequently hallucinate the parameter syntax or forget to request the necessary relational data, resulting in missing context. A managed MCP server handles this translation, abstracting the with [] syntax into standard JSON Schema properties that the LLM understands.

Complex Signature State Machines Automating contract signatures in Wiwink is not a single API call. It requires orchestrating a strict, multi-step state machine. You must create the signature entity, upload a raw binary document, attach signers, and explicitly trigger a send operation. Furthermore, you can only cancel a signature if it has been sent and not yet completed. LLMs naturally try to compress operations into a single step. You must strictly guide the model through this state machine using precise schemas and step-by-step tool definitions. Building this orchestration logic into a custom MCP server is brittle and time-consuming.

Explicit Rate Limiting and Backoff Strategy Wiwink, like all enterprise SaaS, enforces rate limits. A common mistake engineers make is trying to build automatic retries into the MCP server itself. Truto takes a different architectural approach: it does not retry, throttle, or apply backoff on rate limit errors. When Wiwink returns an HTTP 429 Too Many Requests, Truto passes that error directly to the caller. It normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec. The caller (the LLM or your agentic framework) is responsible for interpreting the 429 error and executing the retry and backoff. This ensures your agent maintains accurate state and does not hang silently waiting on a server-side retry loop.

How to Generate a Wiwink MCP Server with Truto

Truto dynamically derives MCP tool definitions directly from Wiwink's integration resources and documentation records. You do not have to write a single line of schema mapping code.

There are two ways to generate an MCP server in Truto: via the UI or programmatically via the API.

Method 1: Generating the Server via the Truto UI

For internal tooling and administrative use cases, the easiest path is the Truto UI:

1. Log into your Truto dashboard and navigate to the integrated account page for your connected Wiwink instance.
2. Click the MCP Servers tab.
3. Click Create MCP Server.
4. Configure the server. You can optionally restrict access by HTTP method (e.g., read-only) or apply tags to limit the exposed tools.
5. Copy the generated MCP server URL. This URL contains a cryptographically secure, hashed token.

Method 2: Generating the Server via the API

If you are building a multi-tenant B2B application and need to dynamically provision MCP servers for your end-users, you can automate this using the Truto API. (See our how-to guide on generating MCP servers for SaaS users for more on this architecture).

Make a POST request to /integrated-account/:id/mcp. You can pass a config object to filter the available tools.

// Example using fetch to create a Wiwink MCP server
const response = await fetch('https://api.truto.one/integrated-account/<wiwink-account-id>/mcp', {
  method: 'POST',
  headers: {
    'Authorization': 'Bearer YOUR_TRUTO_API_KEY',
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    name: "Wiwink Operations Server",
    config: {
      methods: ["read", "write"], // Expose both GET/LIST and POST/PATCH/DELETE
      require_api_token_auth: false
    },
    expires_at: null // Set to an ISO datetime for temporary access
  })
});
 
const mcpServer = await response.json();
console.log(mcpServer.url); 
// Returns: https://api.truto.one/mcp/a1b2c3d4e5f6...

How to Connect the Wiwink MCP Server to Claude

Once you have the Truto MCP URL, you need to register it as a tool server with Claude. This gives the model the ability to discover and execute Wiwink API endpoints.

Method 1: Via the Claude UI

If you are using Claude Desktop or the Claude web interface (depending on your Anthropic plan):

1. Open Claude and navigate to Settings.
2. Click on Integrations or Connectors.
3. Select Add MCP Server or Add custom connector.
4. Paste the Truto MCP URL (https://api.truto.one/mcp/...) and save.

Claude will immediately ping the /initialize endpoint, complete the JSON-RPC 2.0 handshake, and load the available Wiwink tools.

Method 2: Via Manual Configuration File (Claude Desktop)

For developers using the Claude Desktop app, you can manually configure the server using the claude_desktop_config.json file. Since Truto provides a standard HTTP endpoint, we use the official @modelcontextprotocol/server-sse proxy to translate Claude's local standard I/O into Server-Sent Events/HTTP requests.

Open your configuration file (usually located at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS) and add the following:

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

Restart Claude Desktop. The Wiwink tools are now available in your chat context.

Hero Tools for Wiwink Operations

Truto maps Wiwink's endpoints into granular, strictly typed MCP tools. Here are the highest-leverage tools available for orchestrating field service, inventory, and quoting workflows.

list_all_wiwink_works

This tool retrieves a paginated list of work orders. It supports robust filtering, allowing you to isolate works by customer ID, status, type, or a specific date range. Crucially, it supports the with [] parameter, enabling the LLM to pull associated relational data in one pass.

"Find all active work orders scheduled for this week and include the customer details in the response."

create_a_wiwink_proposal

Generates a new proposal or quote in Wiwink. You must supply a valid customer_id. The schema ensures the LLM calculates and submits the correct sub-amounts, discount amounts, and tax percentages.

"Draft a new proposal for customer ID 8914. Set the status to draft and add a comment indicating this is a preliminary quote for the HVAC installation."

list_all_wiwink_installers

Retrieves your roster of field technicians and installers. It accepts query parameters for name, email, phone, city, zipcode, and state ID. This is essential for dispatching logic - allowing the LLM to search for available installers in a specific region.

"List all installers located in zipcode 90210."

create_a_wiwink_work_installer

Assigns an installer to a specific work order. This is a synchronization endpoint that replaces the current installer assignment for the specified work_id.

"Assign the installer 'John Doe' to work order ID 10452."

get_single_wiwink_product_by_id

Fetches the complete record for a product in your inventory, including complex pricing structures (price_retail, price_reduced, price_cost, and their final calculated values) alongside product codes (EAN13, UPC, ISBN).

"Look up product ID 402. I need the final retail price and the required tax percentage."

create_a_wiwink_signature_send

Executes the final step in the Wiwink signature lifecycle. This tool requires a valid signature_id and will only succeed if the signature record already has a document and signers attached.

"Send the signature request for signature ID 992. Confirm the sent timestamp once completed."

To view the complete inventory of available Wiwink tools, including schemas and required properties for endpoints covering contacts, statuses, and forms, view the Wiwink integration page.

Workflows in Action

Exposing tools is only the first step. The true power of an MCP server is allowing Claude to orchestrate multi-step workflows. Here are two real-world operational scenarios.

Workflow 1: Dispatching an Installer to a High-Priority Work Order

When a priority service request comes in, an operations manager needs to locate the work order, find an installer in the correct region, and assign them immediately.

"We have an urgent work order for customer ID 551. Find their open work order, look up an available installer in their city (Seattle), and assign the installer to the job."

How the LLM executes this:

flowchart TD
    A["list_all_wiwink_works<br>Query: customer_id=551, status=open"] --> B["Extract work_id and location"]
    B --> C["list_all_wiwink_installers<br>Query: city=Seattle"]
    C --> D["Extract installer_id"]
    D --> E["create_a_wiwink_work_installer<br>Body: work_id, installer_id"]
    E --> F["Return assignment confirmation"]

1. The model calls list_all_wiwink_works, passing the customer ID and filtering for open statuses to retrieve the target work_id.
2. The model calls list_all_wiwink_installers, passing the customer's city as a search parameter.
3. The model selects a valid installer from the response and calls create_a_wiwink_work_installer to finalize the assignment.
4. Claude summarizes the action, confirming the installer's name and the updated work order details.

Workflow 2: Generating a Proposal and Triggering a Signature

Creating a proposal and dispatching it for signature is a tedious, multi-step process. Claude can handle the entire orchestration.

"Draft a proposal for customer ID 332 totaling $1500 sub-amount with 10% tax. Once drafted, initiate a digital signature process for this proposal, attach the signer 'jane@example.com', and send the request."

How the LLM executes this:

sequenceDiagram
    participant Claude as Claude Desktop
    participant Truto as Truto MCP Server
    participant Wiwink as Wiwink API
    
    Claude->>Truto: Call create_a_wiwink_proposal
    Truto->>Wiwink: POST /proposals
    Wiwink-->>Truto: Returns proposal_id
    Truto-->>Claude: Tool result (proposal_id)
    
    Claude->>Truto: Call create_a_wiwink_signature
    Truto->>Wiwink: POST /signatures
    Wiwink-->>Truto: Returns signature_id
    Truto-->>Claude: Tool result (signature_id)
    
    Claude->>Truto: Call create_a_wiwink_signer
    Truto->>Wiwink: POST /signatures/{id}/signers
    Wiwink-->>Truto: Returns signer confirmation
    Truto-->>Claude: Tool result
    
    Claude->>Truto: Call create_a_wiwink_signature_send
    Truto->>Wiwink: POST /signatures/{id}/send
    Wiwink-->>Truto: Returns sent_at timestamp
    Truto-->>Claude: Tool result

1. Claude calls create_a_wiwink_proposal with the requested financial parameters.
2. Claude takes the resulting proposal data and calls create_a_wiwink_signature to initialize the contract envelope.
3. Claude uses the new signature ID to call create_a_wiwink_signer, attaching the requested email address.
4. Finally, Claude calls create_a_wiwink_signature_send to officially dispatch the email. If the Wiwink API returns an error (e.g., missing a document upload), Claude reads the error and reports back exactly what is missing.

Security and Access Control

When you give an LLM access to your CRM and operational data, security cannot be an afterthought. Truto's managed MCP servers provide granular controls to limit blast radius and enforce authentication:

• Method Filtering: You can restrict a server to read-only operations by setting config.methods = ["read"]. This allows the LLM to query data without any risk of accidental deletions or unauthorized writes.
• Tag Filtering: You can restrict the server to specific resource subsets using config.tags. If you only want an agent managing products, you can filter out all contact and proposal endpoints.
• Secondary API Authentication: By setting require_api_token_auth: true, possession of the MCP URL is no longer sufficient. The caller must also pass a valid Truto API token in the authorization header. This protects URLs that might be exposed in logs or config files.
• Automated Expiry: You can pass an expires_at ISO datetime when creating the server. Truto uses Cloudflare KV and Durable Objects to automatically destroy the server and invalidate the token at the exact minute of expiration - ideal for temporary contractor access or isolated AI testing environments.

Architecting for Scale

Building an integration with Wiwink requires deep domain knowledge of its data structures, pagination methods, and API limitations. Building an integration that an LLM can reliably understand and navigate requires a magnitude more effort in schema design and error handling.

By leveraging a managed MCP server, you eliminate the need to write boilerplate integration code, maintain complex TypeScript interfaces, or deal with token refreshes. Truto translates your Wiwink instance into a clean, machine-readable protocol layer. You focus on engineering the AI agent's logic and prompts; the infrastructure handles the rest.