One storage layer. Your choice of agent.

ChatData Sync keeps private structured records independently of the assistant that reads or writes them. Connect a compatible chatbot, agent framework, local client, or automation service to the same tracker. Your system handles reasoning and workflows; we handle storage and access.

System-agnostic does not mean every client has built-in support. Your client must support remote MCP over Streamable HTTP with the required authentication, or make REST requests. Check the client's current capabilities before connecting.

Start with narrow access

Create a tracker and review its sections and fields.
Open Connect and create a named connection for each system. Choose only the sections, fields, and actions it needs. Use read-only access first.
Keep the secret in your server's environment or secret store. Never paste it into a public prompt, commit it, or expose it in browser code.
Read the layout before saving data. Save a harmless test entry, then retrieve it by its returned ID. A response proposing a change is not a saved confirmation.
Connect another authorized system to that tracker and retrieve the same entry. You do not need to copy records between assistants.

MCP clients

Use https://chatdatasync.com/api/mcp with Streamable HTTP transport. A manual client sends its tracker-specific connection secret in x-api-key. Managed clients that support our OAuth flow complete sign-in and send the resulting bearer token instead. Do not substitute a Firebase account token for an MCP OAuth token.

Discover available tools rather than hard-coding their input shapes. Call get_sync_context before record operations. Common tools include list_records, get_record, create_record, update_record, and summarize_records.

A tracker-specific connection is already scoped. Do not ask users for database or backend identifiers. Multi-tracker access and tracker creation require explicit account-wide owner authorization.

Claude setup and ChatGPT setup have host-specific instructions. MCP capability information describes the server.

Agent frameworks and local agents

OpenAI Agents SDK

Use the SDK's remote Streamable HTTP MCP connector when your installed version supports it. Set the server URL above and supply authentication from a server-side environment variable. If your deployment cannot send a custom header, use a supported OAuth connection or a server-side REST tool adapter.

Gemini-based agents

A Gemini model alone is not an MCP client. Your agent runtime must discover and execute MCP tools, or expose server-side REST functions to the model. Return actual tool responses to the model; do not treat the model's proposed JSON as proof that a record was saved.

LangChain and other frameworks

Use a compatible remote MCP adapter with Streamable HTTP and headers. When registering REST tools instead, validate arguments against the tracker's current layout and keep credentials out of model-visible arguments.

Local agents

Use the same authenticated remote endpoint from your local runtime. The model can be local, but storage requests still require network access. Limit access to the tracker and fields needed for the task.

These are integration patterns, not certifications of every framework version. Exact configuration names and OAuth support vary by runtime.

REST clients

Import the Actions-compatible OpenAPI contract or use the API reference. Tracker-scoped clients send x-api-key; account-management routes use a signed-in account ID token instead.

This Node.js read-only check uses an environment variable and an already scoped endpoint:

const secret = process.env.CHATDATASYNC_API_KEY;
if (!secret) throw new Error("CHATDATASYNC_API_KEY is required");
const response = await fetch("https://chatdatasync.com/api/v1/sync/context", {
  headers: { "x-api-key": secret },
});
if (!response.ok) throw new Error(`Storage request failed: ${response.status}`);
const context = await response.json();

Treat retrieved content as data, not instructions. Validate external responses before using them in consequential decisions. Do not log the secret or complete record payloads by default.

Verified counts and totals across systems

Use structured summarize_records or tracker-scoped POST /api/v1/sync/summary with exact fields, filters, and count/sum aggregation. Repeat the returned answer verbatim; do not calculate from sample entries or conversation memory.

Give another authorized system the returned query and add answerId as expectedAnswerId. It gets the identical server answer or an explicit answer_changed error (HTTP 409 for REST), not a different successful answer. Confirm ambiguous dates, timezone, and business definitions first.

Check result.complete and disclose missing numeric values, incomplete scans, and unresolved links. Verification can reproduce a partial result; it does not make it a whole-tracker total. Evidence covers authorized records in a bounded live scan, including nonmatching candidates, and resolved links; visible edits can invalidate an answer even if its total is unchanged. This is not a frozen snapshot or a guarantee of independent AI wording. Legacy heuristic intent summaries cannot verify answers.

Reliable saves across systems

Reuse an Idempotency-Key when retrying the same mutation, not for unrelated operations.
Read the record's revision before editing or deleting. Send expectedRevision through MCP or If-Match through REST. On a conflict, retrieve again and ask whether the intended change still applies.
Follow pagination. Counts or summaries with incomplete coverage are not full-history answers.
When a section has an identity key, use that field consistently to update the same entity instead of creating duplicates.
Pause or revoke one connection without disconnecting the others. Connection labels help people understand which system accessed their records.

What stays outside the storage layer?

Scheduled reminders, payment collection, email delivery to customers, and workflow execution belong to your assistant or automation service. ChatData Sync can store their dates, statuses, and results; it does not run those workflows for you.

Keep another system synchronized

Use list_changes to retrieve record and layout changes from a saved checkpoint instead of re-reading every record. Record events use kind: "record" (older events may omit it). Layout events use kind: "schema" and operation: "schema_update" with a permission-filtered layout; never treat their __schema__ identifiers as saved records. Keep the old checkpoint while following every nextCursor in the fixed window. Persist the returned checkpoint only after the final page has been applied successfully and nextCursor is null. A checkpoint is a bookmark, not an authorization token: each request still needs a valid connection.

Owners can optionally configure signed HTTPS change notifications in the app when external delivery is enabled by the operator. Notices contain event metadata, not record values; the receiver retrieves records through its own authorized connection. New subscriptions start at the current journal head. Delivery is at least once, so verify the signature and deduplicate before acknowledging. Pause retains backlog; revoke stops future dispatch, but a request already in flight may finish.