Use AI tools with the campai API

An AI-assisted integration still needs an ordinary authenticated backend. Use the API contract to understand operations, then expose a small set of reviewed functions to your assistant. Keep credentials and organization scope in trusted server configuration.

This pattern can support an assistant used through Claude, ChatGPT, or your own interface. It does not imply that campai provides an official connector for those products, and importing an OpenAPI document does not establish such a connection.

Choose one task with a clear input and a small result. For example, an assistant can report how many member contacts match the accessible mandate. It does not need every member's address, a generic HTTP proxy, or permission to change records to answer that question.

Use the setup from Make your first API request. Configure the organization and mandate on the server and grant only Mandates → Read and Members → Read. The model should not choose the key, API host, organization, or mandate from chat text.

Verify the API request before connecting it to an AI platform. Replace YOUR_API_KEY, YOUR_ORGANIZATION_ID, and YOUR_MANDATE_ID directly in your chosen example. Each tab is complete and uses only cURL or the runtime’s built-in functions. List contacts accepts limit: 0 for a count-only request, so no contact records need to leave campai.

curl --fail-with-body --silent --show-error --max-time 30 --globoff \
  --request POST 'https://cloud.campai.com/api/YOUR_ORGANIZATION_ID/YOUR_MANDATE_ID/crm/contacts/list' \
  --header 'X-API-Key: YOUR_API_KEY' \
  --header 'Content-Type: application/json' \
  --data-raw '{
  "types": [
    "member"
  ],
  "limit": 0,
  "offset": 0,
  "returnCount": true
}'

Wrap the request in a no-argument read tool on your server using your chosen platform's tool interface. Authenticate the calling user before executing it. Return only the validated count and check time; do not pass the whole API response to the model.

The result counts accessible contacts with the member type. It is not automatically a count of currently active memberships or paid subscriptions. Preserve that distinction in the tool description and the assistant's answer. A permission or mandate change can also change the count.

Use this small contract when adapting the request to your chosen AI platform. The platform-specific registration is a separate implementation step; the API request above is the part you can run directly here.

Tool property	Value or rule
Name	count_member_contacts
Description	Count accessible contacts with the member type in the configured mandate; not active memberships or paid subscriptions.
Model-supplied input	None. Reject unexpected arguments.
Server configuration	Fixed API host, key, organization, and mandate.
Authorized caller	A signed-in user who may view this organization’s aggregate count.
Successful output	matchingMemberContacts and checkedAt only.
Failed read	A tool error; never a fabricated count of zero.

First end-to-end check after registration: ask for the member-contact count, inspect the tool invocation, and compare its integer result with the same direct request. Then attempt an organization override and an unauthorized call. Both must be rejected by your backend before an API request runs.

Read the contract from the environment you will call. Track changes to the API contract shows how to save it. Select operations deliberately, including their required parameters, response shape, and permission requirements.

Do not classify operations only by HTTP method. Several list operations use POST while remaining read-only. Conversely, an operation with an innocuous name may queue work or change state. Review its behavior before exposing it as a tool.

Avoid automatically registering the entire API catalogue. A small allowlist makes it possible to validate inputs, explain results accurately, and test each tool. Fix the base URL in your backend so the assistant cannot redirect an authenticated request to a different server.

For a future write tool, have the assistant propose a structured change. Your backend should validate the schema, resolve records within the authenticated user's scope, and present the exact target and effect for review. After approval, execute the narrowly defined operation and record its outcome.

For example, drafting an invoice payload and calling Create invoice are different steps. Sending a financial document or performing a payment action requires an additional explicit workflow. Do not let a broad natural-language request silently authorize every available finance operation.

Re-fetch important state before execution and handle uncertain writes using the retry and reconciliation rules. The model's assertion that a request succeeded is not evidence; use the API result and, where appropriate, a read-back check.

Names, descriptions, notes, and uploaded documents may contain arbitrary text. Such text must not override your tool permissions, choose a new destination, or instruct the assistant to reveal credentials. Enforce these boundaries in server code, not only in a prompt.

Return only fields needed for the user's task. Keep API keys, raw error details, private documents, and full contact records out of model input unless that specific data use is intended and authorized. Log tool name, permitted scope, status, and correlation ID rather than entire responses by default.

First test the exact API call without a model. Then test the registered tool with a normal request, an unauthorized user, an attempted organization override, malformed arguments, an API failure, and misleading instructions embedded in returned text. The backend must enforce the same scope in every case.

A campai developer app is a different hosting option. Its server permissions and secrets govern code running inside campai; they do not automatically provide an AI platform connection or permission to send organization data to a model provider.