Connect Sendoso to Claude: Manage Teams and Track Gift Sends
Learn how to connect Sendoso to Claude using a managed MCP server. Automate physical gifts, eGifts, and user provisioning through native AI tool calling.
If you need to connect Sendoso to Claude to automate corporate gifting campaigns, manage user budgets, or track physical send statuses, you need a Model Context Protocol (MCP) server. This server acts as the translation layer between Claude's natural language tool calls and Sendoso's REST API. 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 Sendoso to ChatGPT or explore our broader architectural overview on connecting Sendoso to AI Agents.
Giving a Large Language Model (LLM) read and write access to your corporate gifting platform is an engineering challenge with real financial stakes. You have to handle OAuth 2.0 token lifecycles, map polymorphic JSON schemas for different gift types to MCP tool definitions, and deal with strict vendor-specific API limitations. Every time Sendoso updates a resource or deprecates a parameter, 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 Sendoso, connect it natively to Claude, and execute complex gifting workflows using natural language.
The Engineering Reality of the Sendoso 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 Sendoso's APIs is painful. You are not just integrating "gifts" - you are integrating complex supply chain logic, team budget allocations, and polymorphic payload structures.
If you decide to build a custom MCP server for Sendoso, you own the entire API lifecycle. Here are the specific challenges you will face when translating Sendoso's REST endpoints into reliable LLM tools:
Polymorphic Send Schemas
Sendoso does not have a single POST /send endpoint that handles everything cleanly. The payload requirements vary wildly depending on the type of gift. Sending an eGift requires a target email, a touch_id, and a via delivery method. Sending a physical gift requires full shipping address objects. Sending a physical gift with address collection requires an entirely different set of boolean flags (no_address, confirm_address, resume_with_unconfirmed_address). If you expose these complex, overlapping schemas directly to an LLM without strict JSON Schema definitions, Claude will frequently hallucinate fields, mixing physical address requirements with eGift payloads and causing validation errors.
The Touch ID Dependency Chain
You cannot instruct an LLM to "Send a coffee gift card to Jane". Sendoso's architecture requires you to map every send to a specific Campaign and Touch ID. A "Touch" represents the specific offering configured in your Sendoso account. This forces a multi-step API orchestration: your agent must first query the campaigns list, identify the active campaign, extract the relevant touch_id, and then inject that identifier into the subsequent send request. Your MCP server must accurately describe this operational prerequisite to the model, or the agent will stall out trying to guess IDs.
Strict Rate Limits and Error Handling
Sendoso enforces API rate limits to protect their infrastructure. If your AI agent gets stuck in a loop querying hundreds of send statuses, it will trigger an HTTP 429 Too Many Requests error. It is critical to note that Truto does not retry, throttle, or apply backoff on rate limit errors. When the Sendoso API returns a 429, Truto passes that error directly to the caller. Truto normalizes the upstream rate limit info into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec. The MCP client (or the engineer writing the agent execution loop) is solely responsible for implementing intelligent retry and backoff logic.
Instead of building schema validation, OAuth flows, and pagination handling from scratch, you can use Truto. Truto derives tool definitions directly from Sendoso's API resources, normalizes authentication, and exposes the endpoints as ready-to-use MCP tools.
How to Generate a Sendoso MCP Server with Truto
Truto automatically generates a set of MCP tools from your connected Sendoso account based on the integration's resource definitions. Each MCP server is scoped to a single integrated account, meaning the server URL contains a cryptographic token that fully authenticates the requests.
You can create this server in two ways: through the Truto UI or programmatically via the API.
Method 1: Generating the Server via the Truto UI
If you are setting up Claude Desktop for internal operations, the UI is the fastest path.
- Log into your Truto dashboard and navigate to the Integrated Accounts list.
- Select your connected Sendoso account.
- Click the MCP Servers tab.
- Click Create MCP Server.
- Select your desired configuration. You can name the server, filter it to specific methods (e.g., read-only), or set an expiration date.
- Click Create and copy the generated MCP server URL. You will not be able to see this specific URL again.
Method 2: Generating the Server via the API
If you are dynamically provisioning AI agents for your own SaaS platform users, you will generate MCP servers programmatically.
Truto validates that the integration has tools available, generates a secure token, stores the metadata, and returns a ready-to-use JSON-RPC endpoint. The token is cryptographically hashed before storage, ensuring that even internal database access does not expose your active server URLs.
Request:
curl -X POST https://api.truto.one/integrated-account/YOUR_SENDOSO_ACCOUNT_ID/mcp \
-H "Authorization: Bearer YOUR_TRUTO_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"name": "Sendoso SDR Agent Server",
"config": {
"methods": ["read", "write"],
"tags": ["campaigns", "sends", "users"]
}
}'Response:
{
"id": "mcp_srv_8f9a2b3c",
"name": "Sendoso SDR Agent Server",
"config": {
"methods": ["read", "write"],
"tags": ["campaigns", "sends", "users"]
},
"expires_at": null,
"url": "https://api.truto.one/mcp/t_a1b2c3d4e5f6g7h8..."
}The url returned in this response is the fully authenticated JSON-RPC 2.0 endpoint that you will provide to Claude.
How to Connect the Sendoso MCP Server to Claude
Once you have your Truto MCP URL, connecting it to an LLM client requires zero additional coding. The client uses the MCP handshake protocol (initialize, tools/list) to automatically discover all available Sendoso operations.
Method A: Via the Claude UI
If you are using the consumer versions of Claude or ChatGPT, you can add the connector directly in the application settings.
- For Claude (Desktop or Web): Go to Settings -> Integrations -> Add MCP Server. Paste your Truto MCP URL and click Add.
- For ChatGPT: Go to Settings -> Apps -> Advanced settings. Enable Developer mode. Under Custom connectors, add a new server, name it "Sendoso", paste the URL, and save.
The application will immediately ping the server and populate the model's context with the Sendoso tool schemas.
Method B: Via Manual Configuration File
For enterprise deployments using Claude Desktop, or if you are running custom agents in environments like Cursor, you configure the connection using a JSON file. Because Truto provides the server over standard HTTP via Server-Sent Events (SSE), you use the official @modelcontextprotocol/server-sse transport.
Edit your claude_desktop_config.json file (typically located at ~/Library/Application Support/Claude/claude_desktop_config.json on macOS):
{
"mcpServers": {
"sendoso_truto": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-sse",
"https://api.truto.one/mcp/t_a1b2c3d4e5f6g7h8..."
]
}
}
}Restart Claude Desktop. The model now has direct API access to your Sendoso instance. You can use the same configuration pattern to connect Google Workspace to Claude for broader workspace automation.
Core Sendoso Operations
Truto normalizes the Sendoso API into predictable, snake_case tool names with fully hydrated JSON Schema definitions. Below are the highest-leverage hero tools your AI agent will use to orchestrate gifting workflows.
list_all_sendoso_campaigns
This tool is the prerequisite for almost every other Sendoso operation. Because gifts must be tied to specific touches, your agent will use this tool to scan active campaigns and locate the required touch_id for fulfillment.
"List all of our active Sendoso campaigns. I need to find the touch ID for the 'Q4 Executive Wine Box' campaign so we can send it out today."
create_a_sendoso_egift
Executes the delivery of a digital gift card directly via email. The LLM handles mapping the recipient details and selecting the appropriate delivery method.
"Send a $50 Starbucks eGift to sarah.connor@example.com using the 'Prospect Coffee' touch ID you just found. Ensure the delivery via method is set to email."
create_a_sendoso_physical_gift_address_collection
One of the most powerful automated tools for SDR teams. When you want to send a physical item but do not have the recipient's home address, this tool dispatches an address confirmation request. The agent must pass specific boolean flags like no_address and confirm_address.
"I want to send the 'Welcome Swag Kit' to john.doe@partner.com, but I don't know where he lives. Create a physical gift send using address collection. Set it to expire after 14 days if he doesn't respond."
list_all_sendoso_sends
This tool allows the LLM to query the status of historical or active deliveries. It returns granular tracking information, cost data, and delivery status updates, allowing the agent to answer pipeline questions.
"Check the status of all Sendoso sends created this week. Did the Executive Wine Box get delivered to Sarah yet? Give me the tracking code if it has shipped."
list_all_sendoso_groups
Sendoso manages budgets and access via Team Groups. This tool allows the agent to audit active groups, check current budget allocations, and retrieve the team_group_id necessary for adding new employees to the platform.
"List all of our Sendoso team groups. What is the current remaining budget for the 'Enterprise Sales' group, and what is its group ID?"
create_a_sendoso_user
Automates the provisioning of new senders within your Sendoso organization. The LLM maps the employee's email to a specific team group, bypassing manual HR requests.
"Create a new Sendoso user invitation for our new hire, alex.smith@company.com. Add him to the 'Enterprise Sales' team group using the ID you just retrieved."
For the complete tool inventory and granular schema definitions, see the Sendoso integration page.
Workflows in Action
When you combine an LLM's reasoning engine with Truto's dynamic tool generation, you unlock multi-step orchestration. The agent no longer just reads data - it acts as an autonomous operator. Here is how specific personas use this setup in production.
Scenario 1: The Account Executive "Close" Workflow
An Account Executive wants to instantly deploy a high-value physical gift to a champion after signing a contract, without logging into a separate portal or hunting down a shipping address.
"We just closed the Acme Corp deal. Send the 'Executive Celebration Hamper' to their VP, michael.scott@acmecorp.com. I don't have his home address, so send an address collection request. After you do that, check the status to give me the tracking link format."
Step-by-step Execution:
- The agent calls
list_all_sendoso_campaignsto search for "Executive Celebration Hamper" and extracts the associatedtouch_id. - The agent calls
create_a_sendoso_physical_gift_address_collection, passing thetouch_id, Michael's email, and settingno_address: trueandconfirm_address: true. - The agent calls
list_all_sendoso_sendsto verify the creation and parses the response to return the Sendoso tracking URL structure back to the Account Executive.
Scenario 2: The HR Onboarding & Provisioning Workflow
An IT administrator needs to onboard a new sales rep, give them Sendoso sending permissions, and immediately dispatch their physical welcome kit.
"We have a new SDR starting today: emily.blunt@company.com. Provision her a Sendoso account under the 'SDR Team' budget group. Then, send her the 'New Hire Swag Box' eGift link so she can claim her laptop stickers."
Step-by-step Execution:
- The agent calls
list_all_sendoso_groupsto find the exact ID for the "SDR Team". - The agent calls
create_a_sendoso_user, passing Emily's email and the retrievedteam_group_id. - The agent calls
list_all_sendoso_campaignsto locate thetouch_idfor the "New Hire Swag Box". - The agent calls
create_a_sendoso_egift_linkto generate a direct redemption link for the swag, outputting the generated URL so the admin can drop it into Slack.
Security and Access Control
Giving an AI agent programmatic write access to an enterprise gifting platform requires strict governance. Truto's MCP tokens are designed with explicit guardrails that are enforced at the server level.
- Method Filtering: You can restrict a token to specific operation types. Setting
config.methods: ["read"]ensures the agent can query campaign IDs and track sends, but physically cannot invokecreateendpoints to spend money. - Tag Filtering: Integrations define functional tags. You can pass
config.tags: ["users"]to create an HR-specific MCP server that can only view and create users, completely isolating it from the physical gifting endpoints. - Expiration Controls: Using the
expires_atparameter, you can generate ephemeral MCP servers. This is ideal for granting a contractor temporary access to deploy a specific campaign, automatically revoking the endpoint via a distributed alarm system when time expires. - Secondary Authentication: By setting
require_api_token_auth: true, the URL alone is no longer enough to invoke tools. The MCP client must also pass a valid Truto API token via a Bearer header. This protects your enterprise budget even if the MCP URL is accidentally leaked in logs or shared workspaces.
Scaling Sendoso Operations with MCP
Building a custom integration between AI models and Sendoso forces your engineering team to take on perpetual maintenance. You must handle the complexities of Touch IDs, manage varying JSON schemas for different gift modalities, and write the infrastructure to manage token refreshes and error handling.
By generating a Sendoso MCP server through Truto, you bypass the boilerplate. You get fully documented, LLM-ready tools derived directly from the vendor's API resources. Whether you are automating SDR outbound motions, tracking global inventory fulfillment, or managing team gifting budgets, Truto provides the secure, standardized infrastructure layer needed to turn Claude into a fully capable Sendoso administrator.
FAQ
- Does Truto handle Sendoso API rate limits automatically for my AI agents?
- No. Truto does not retry, throttle, or apply backoff on rate limit errors. When the Sendoso API returns an HTTP 429 Too Many Requests, Truto passes that error to the caller. Truto normalizes the upstream rate limit info into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) per the IETF spec. The MCP client or agent is responsible for implementing retry and backoff logic.
- How do I prevent Claude from accidentally spending our entire Sendoso budget?
- You can use Truto's method filtering and tag filtering when generating the MCP token. By setting the MCP server config to read-only methods, or restricting it to specific tags, you ensure the LLM can only query campaign data or track sends, rather than executing new physical or eGift sends.
- Can I use the Sendoso MCP server with tools other than Claude Desktop?
- Yes. Because Truto exposes a standard JSON-RPC 2.0 endpoint, the MCP server URL can be used with any MCP-compatible client. This includes ChatGPT Desktop, Cursor, custom LangChain agents, or automated CI/CD workflows.