Connect SpringVerify US to ChatGPT: Automate Screening and Reports

If you need to connect SpringVerify US to ChatGPT to automate candidate screenings, manage billing approvals, or extract insights from completed background check PDFs, you need a Model Context Protocol (MCP) server. This server acts as the critical translation layer between ChatGPT's tool calls and the SpringVerify US 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.

Giving a Large Language Model (LLM) read and write access to highly sensitive HR infrastructure like a background check system is an engineering challenge. You have to handle unique billing architectures, map nested candidate schemas to MCP tool definitions, and deal with PDF proxy downloads. Every time the API updates, you have to update your server code, redeploy, and test the integration. If your team uses Claude, check out our guide on connecting SpringVerify US to Claude or explore our broader architectural overview on connecting SpringVerify US to AI Agents.

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

The Engineering Reality of the SpringVerify US 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 over JSON-RPC 2.0, the reality of implementing it against specific vendor APIs is painful. You aren't just integrating a simple CRUD app - you are integrating an asynchronous background verification engine with strict billing constraints and unstructured data outputs.

If you decide to build a custom MCP server for SpringVerify US, you own the entire API lifecycle. Here are the specific integration challenges that break standard REST assumptions when working with this system:

The Decoupled Invite and Billing Flow In many SaaS platforms, creating a user is a single POST request. In SpringVerify US, creating a candidate and actually initiating their background check are separated by billing logic. You often have to ensure a payment method is on file (spring_verify_us_company_save_cc), create the candidate (create_a_spring_verify_us_candidate), and then explicitly authorize a charge for that specific invite (spring_verify_us_company_payment_for_invite). If your custom server doesn't expose these as distinct, sequentially documented tools, the LLM will attempt to invite candidates without funding the transaction, resulting in silent workflow failures.

PDF Report Extraction The ultimate output of a SpringVerify US screening is a PDF report. LLMs cannot read raw binary streams natively without an intermediate processing step. The spring_verify_us_candidates_report endpoint returns proxy data that must be handled carefully. Your custom server must manage the file download, potentially convert it to text, or return a structured pre-signed URL that the LLM's environment can access. Truto handles the proxying of this data automatically, but if you build it yourself, you are responsible for file buffering and memory management on the server edge.

Asynchronous State via Webhooks Background checks take days. An LLM cannot hold a connection open waiting for a county court to return a record. To build a robust AI agent on top of SpringVerify US, you need to manage webhooks programmatically (create_a_spring_verify_us_webhook). Your agent must be able to list, create, and verify webhook delivery endpoints so it can be notified when a candidate's status shifts from pending to complete. Managing webhook signature verification and routing payloads back into the LLM's context window is a massive infrastructure burden if built from scratch.

Rate Limits and 429 Exhaustion Background screening APIs strictly limit request velocity to prevent abuse. If an AI agent enters a loop while polling candidate statuses, it will hit a 429 Too Many Requests error. It is critical to note how Truto handles this: Truto does not retry, throttle, or apply exponential backoff on rate limit errors. When the upstream SpringVerify US API returns a 429, Truto immediately passes that error back to the caller. However, Truto normalizes the upstream rate limit information into standardized headers (ratelimit-limit, ratelimit-remaining, ratelimit-reset) conforming to the IETF specification. The caller (the LLM client or agent framework) is fully responsible for reading these headers and executing its own backoff logic.

Instead of forcing your engineering team to build and maintain this translation layer, you can use Truto to generate a managed MCP server in seconds.

How to Generate the SpringVerify US MCP Server

Truto dynamically derives MCP tools from an integration's existing resource definitions and documentation records. A tool only appears in the MCP server if it has a corresponding documentation entry - this acts as a quality gate to ensure ChatGPT only sees well-documented endpoints.

Each server is scoped to a single connected SpringVerify US account and is authenticated via a cryptographically hashed token embedded in the URL. You can generate this server using the Truto UI or programmatically via the API.

Method 1: Via the Truto UI

If you are an IT admin or developer setting up an agent manually, the UI is the fastest path.

1. Navigate to the Integrated Accounts page in your Truto dashboard.
2. Select your connected SpringVerify US account.
3. Click the MCP Servers tab.
4. Click Create MCP Server.
5. Select your desired configuration (e.g., name, method filters like 'read' or 'write', tag filters, and expiration time).
6. Copy the generated MCP server URL. It will look like https://api.truto.one/mcp/a1b2c3d4e5f6...

Method 2: Via the Truto API

If you are building a product that deploys AI agents for your end-users, you can generate MCP servers programmatically. This provisions a secure token, stores the hash in distributed edge storage, and returns a ready-to-use URL.

Send an authenticated POST request to /integrated-account/:id/mcp:

curl -X POST https://api.truto.one/integrated-account/YOUR_ACCOUNT_ID/mcp \
  -H "Authorization: Bearer YOUR_TRUTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "ChatGPT Candidate Screening Agent",
    "config": {
      "methods": ["read", "write"],
      "tags": ["candidates", "billing"]
    }
  }'

The API returns the database record along with the connection URL. This URL is fully self-contained and ready to be plugged into ChatGPT.

How to Connect the MCP Server to ChatGPT

Once you have your Truto MCP server URL, you must register it with your LLM client. All communication happens over HTTP POST using JSON-RPC 2.0 messages.

Method 1: Via the ChatGPT UI

If you are using the ChatGPT desktop app or web interface on an eligible plan (Pro, Plus, Enterprise, Education):

1. In ChatGPT, navigate to Settings -> Apps -> Advanced settings.
2. Enable Developer mode (MCP support requires this flag).
3. Under MCP servers or Custom connectors, click to add a new server.
4. Name: Enter a recognizable label (e.g., "SpringVerify US via Truto").
5. Server URL: Paste the Truto MCP URL you generated in the previous step.
6. Save the configuration. ChatGPT will instantly perform a protocol handshake, calling the initialize and tools/list endpoints to discover the available operations.

(Note: If you are connecting to Claude Desktop instead, go to Settings -> Integrations -> Add MCP Server, paste the URL, and click Add).

Method 2: Via Manual Config File

If you are integrating this into a custom agent framework, a local testing environment, or relying on SSE (Server-Sent Events) transports, you can define the server in your standard MCP JSON configuration file using the remote server utility:

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

Restart your agent framework, and it will automatically ingest the SpringVerify US schemas.

Hero Tools for Background Verification Ops

Truto maps the SpringVerify US API into descriptive, snake_case tool names derived directly from the API schemas. Here are the highest-leverage tools available to your AI agent.

create_a_spring_verify_us_candidate

This tool allows the LLM to initiate a new background verification case by creating or inviting a candidate. It requires specific payload structures, usually encompassing the candidate's name, email, and the specific package of checks being requested.

Contextual note: Creating a candidate does not always automatically trigger processing. Depending on your SpringVerify US account configuration, you may need to chain this tool with the billing endpoint to authorize the charge.

"We just extended an offer to Jane Doe (jane.doe@example.com). Please invite her as a candidate in SpringVerify US using the 'Standard Pre-Employment' package. Let me know once the invite is sent."

spring_verify_us_company_payment_for_invite

Background checks cost money. This tool allows the agent to execute the billing flow associated with a specific candidate invite. It prevents checks from sitting in a suspended state due to lack of payment authorization.

Contextual note: The LLM must be explicitly instructed to capture the candidate or invite ID from the previous creation step and pass it into this tool to link the payment to the correct record.

"Approve the charge for the background check invite we just created for candidate ID 847392. Confirm when the payment authorization clears."

get_single_spring_verify_us_candidate_by_id

This read-only tool fetches the real-time status of a background verification case. The query schema requires the candidate's unique ID. It returns nested data detailing which specific checks (criminal, education, employment verification) are pending or completed.

Contextual note: Because LLMs flatten input namespaces, the id property is automatically injected into the query schema. The agent will accurately map the requested ID to the endpoint path.

"Check the status of candidate ID 847392. Summarize which specific background checks are still pending and which have cleared."

spring_verify_us_candidates_report

When a case finishes, the end result is a PDF report. This tool interacts with the proxy API to download the SpringVerify US PDF report for a completed verification case.

Contextual note: LLMs cannot display binary PDF blobs in chat. Ensure your agent is instructed to use this tool to retrieve the proxy URL or raw data, and then pass it to a secondary document parsing tool if you expect the LLM to summarize the contents of the report.

"The background check for ID 847392 is marked complete. Retrieve the candidate report and summarize the criminal history findings section."

create_a_spring_verify_us_webhook

Instead of polling the API blindly and burning through rate limits, intelligent agents set up webhooks. This tool creates a webhook endpoint to listen for specific events, such as a candidate status changing to completed.

Contextual note: Your agent needs to know the destination URL of your receiving server before it can successfully configure the webhook using this tool.

"Create a webhook in SpringVerify US pointing to 'https://api.mycompany.com/webhooks/springverify'. Configure it to listen only for the 'candidate.completed' event."

For the complete inventory of available operations, including company profile syncing and webhook log retrieval, view the SpringVerify US integration page.

Workflows in Action

Giving ChatGPT access to individual tools is useful, but the real power of MCP lies in multi-step agentic workflows. Here is how ChatGPT sequences SpringVerify US operations in real-world scenarios.

Scenario 1: Automated Candidate Onboarding and Billing

When an HR recruiter finalizes an offer, they want the screening process to start immediately without navigating through external dashboards.

"We are hiring John Smith (john.smith@example.com) for the engineering role. Please start a background check using the 'Comprehensive Tech' package and authorize the payment for his invite."

Execution Steps:

1. Tool Call 1: create_a_spring_verify_us_candidate. ChatGPT constructs the JSON body containing John's details and the specified package. It executes the tool and receives a response containing the new candidate's id.
2. Tool Call 2: spring_verify_us_company_payment_for_invite. Recognizing that the invite requires payment approval, ChatGPT immediately takes the id from the first response and passes it into the payment tool.
3. Result: ChatGPT responds: "John Smith has been invited to complete his background check. The invite was successfully created (ID: 99482) and the company payment has been authorized. You will be notified when he begins the process."

Scenario 2: Auditing Status and Extracting Results

A compliance officer needs to know if a specific cohort of new hires has cleared their background checks, and needs a summary of any flagged items.

"Check the SpringVerify US status for candidate ID 77382. If the status is complete, download the report and tell me if there are any discrepancies in their education verification."

Execution Steps:

1. Tool Call 1: get_single_spring_verify_us_candidate_by_id. ChatGPT queries the candidate endpoint and inspects the status field in the JSON response.
2. Logic Gate: The LLM observes that the status is completed.
3. Tool Call 2: spring_verify_us_candidates_report. ChatGPT invokes the report proxy tool using the candidate ID.
4. Result: ChatGPT parses the returned data (or URL, depending on your environment's file handling) and replies: "Candidate 77382 has completed their background check. I reviewed the education verification section of the report, and the candidate's degree from State University has been successfully verified with no discrepancies."

Security and Access Control

Exposing an HR and compliance API to an AI model requires strict governance. Truto provides four mechanisms to lock down your SpringVerify US MCP servers:

• Method Filtering: You can restrict a server to specific operations. By passing config: { methods: ["read"] } during creation, the server will silently drop all create, update, and delete tools. The LLM simply won't know they exist.
• Tag Filtering: Limit the server's surface area to specific functional domains. If you only want an agent to handle billing, pass config: { tags: ["billing"] }, and only company payment endpoints will be exposed.
• Expiration (TTL): Set an expires_at timestamp. This provisions a temporary token. Truto handles the cleanup via distributed alarms, automatically destroying the server when time expires - perfect for temporary contractor access.
• Additional Authentication: By default, the cryptographically secure MCP URL is the only auth required. For zero-trust environments, enable require_api_token_auth: true. The client must then pass a valid Truto API bearer token in the headers alongside the connection URL.

Building an AI agent that interfaces with SpringVerify US is rarely a straightforward REST implementation. You have to handle fragmented billing flows, proxy binary PDFs, manage webhook lifecycles, and carefully orchestrate rate limits across your entire tenant architecture. By leveraging Truto's auto-generated MCP servers, you eliminate the boilerplate and schema maintenance. You get a production-ready, highly secure connection that allows ChatGPT to focus on what it does best - orchestrating complex human workflows - while Truto handles the underlying infrastructure.