Customer-submitted context for AI access

Agent integration reference

BaseCite is an evidence intake and bounded context service for organizations that need customer-submitted materials to remain private while selected context can be read by authorized AI systems. The service does not make truth, company, source-authority, legal-authority, certification, ranking, or recommendation claims.

The public discovery layer is intentionally safe to crawl. It exposes service identity, API capabilities, integration documentation, registry links, skill manifests, and boundary statements. It does not expose customer originals, full OCR text, private object keys, private uploads, or a list of all customers or records.

Start an integration with the capabilities document and the OpenAPI contract. The capabilities document describes supported operations and authentication requirements. The OpenAPI contract provides operation identifiers, typed request and response schemas, rate-limit semantics, asynchronous status fields, and the canonical versioned API paths.

Before using production credentials, an agent can use the free isolated sandbox. A sandbox key is ephemeral, scoped only to the no-persistence echo contract, and cannot access uploads, customer records, AI context, R2, S3, or D1. The public signup page issues a sandbox key without a production account or a sales contact.

Sandbox onboarding is self serve. Send a POST request to the sandbox key endpoint with an optional email field, retain the returned token only for the short test window, and call the sandbox echo endpoint with a bearer token. The response confirms the sandbox environment and does not persist submitted probe data.

Production authentication is tenant scoped. A production client must use a provisioned organization credential or the documented OAuth token exchange, then identify one organization and one upload for each authenticated operation. Credentials must remain on a server and must never be embedded in browser code, public skills, or source examples.

Upload processing is asynchronous. A successful completion request can return HTTP 202 with a job identifier, a canonical status URL, a Location header, a Retry-After header, and a polling interval. Clients must follow the status reference until a terminal state and must not infer completion from elapsed time alone.

Every mutation uses a stable idempotency key. Clients can retry only when the documented response is retryable and must preserve the same idempotency key. A successful withdrawal is terminal. Clients must not retry it as a new upload or use it to enumerate unrelated records.

The REST API is versioned under /api/v1/. The published policy describes the support window and the response headers used for deprecation and sunset notices. A client should read Deprecation and Sunset headers, consult the replacement operation in the OpenAPI document, and upgrade before the published sunset date.

Rate limits are communicated through both the legacy X-RateLimit headers and the IETF RateLimit headers. A 429 response is retryable only after the advertised reset window. Rate limiting is also an anti-enumeration boundary, so an agent must not use repeated requests to probe organizations, uploads, object keys, or private URLs.

AI-readable context is bounded and provenance-aware. It is returned only when tenant authorization and visibility policy allow it. The response describes what was submitted and how it was served, but it does not certify that a source is true, authoritative, legally sufficient, complete, or safe for a decision.

Withdrawal removes the original and configured derived context according to the retention policy while retaining the deletion receipt and minimum audit metadata needed to demonstrate the operation. A client should treat withdrawn as a terminal state and should surface the receipt rather than request the removed payload.

Model Context Protocol clients can discover the product server through the BaseCite server card and the documentation server through its public metadata. MCP resources contain documentation and public-safe boundaries. Authenticated tools require tenant-scoped credentials and return bounded results rather than raw customer files.

SDK and skill links are published from the official BaseCite documentation. The JavaScript SDK is distributed through npm and the Python SDK through PyPI. The public agent repository contains installable skills and integration guidance. Package and skill links are references for integration, not substitutes for authentication or customer consent.

For an agent workflow, the recommended order is: read llms.txt, inspect the capabilities and OpenAPI documents, create a sandbox key, run the no-persistence echo probe, configure tenant authentication, initiate one scoped upload, poll its status, read only the authorized bounded context, and record the serving receipt.

BaseCite does not provide unrestricted export, all-record enumeration, raw public downloads, or an unbounded deletion operation. An agent should model one organization and one upload at a time, preserve consent and tenant scope, and stop when the API returns an authorization, policy, rate-limit, or terminal deletion boundary.

Public documentation is available as HTML and Markdown. Agents that do not execute JavaScript can use the Markdown twins, llms.txt, the OpenAPI document, the server cards, and the machine-readable discovery files. These representations are maintained as the same public contract and should be preferred over guessing undocumented URLs.