Bring a person's chosen context into your application. A writing tool can work from approved examples; a project assistant can recover earlier decisions; a planning app can use preferences the person has confirmed.
API access begins through the SEED waitlist. This guide explains the intended integration model. The versioned endpoint reference, supported authorization details and tested request examples will accompany access; no public request path or SDK is specified here yet.
Use the API or MCP
Use the API when your application controls the workflow and makes structured requests to SEED. Use MCP when an AI client discovers the available tools and decides which one to call during a conversation.
Both interfaces should use the same account permissions, record boundaries and correction history. Choosing the API does not grant broader access than connecting an assistant.
SEED keeps the originals and their history. Your application receives the approved information needed for a task. Connecting to SEED does not expose the credentials used to collect data from Google or any other source.
Design around a useful result
| Application | Ask the person to select | Request from SEED | Show in your product |
|---|---|---|---|
| Project assistant | A project collection. | Relevant decisions, constraints and source passages. | A brief with dates and citations. |
| Writing application | Approved samples and a writing brief. | The selected examples and confirmed preferences. | A draft with a way to inspect the material used. |
| Personal planning tool | A small collection of preferences. | Relevant, current context for the plan. | Suggestions the person can review and correct. |
| Preservation helper | A source they want to export. | Public collection guidance. | Official steps, coverage limits and the next action. |
Keep the initial workflow narrow. A useful result from six project notes is a better starting point than importing an entire archive before the person knows what the connection will do.
Authorization belongs to the person
The intended API flow is delegated access: the person signs in to SEED, identifies your application and approves a defined selection and set of operations for a supported period. Your application then uses the credentials issued for that permission.
Keep these boundaries explicit:
- Account: whose records the application may request.
- Recipient: which application receives the context.
- Material: the selected brief, records or collection.
- Operations: the permitted reads or other supported actions.
- Duration: when access expires and how the person can end it.
Follow the credential storage and renewal rules in the published authorization reference when access opens. Never ask a person to paste a vault password, source-service token or account recovery information into your app's prompt.
A record identifier is a reference, not permission. The server must authorize every read, including reads through a citation or a previously returned identifier. A purpose supplied in a request describes the task; it cannot grant additional access.
The request and response model
The proposed retrieval model has three parts: search within the approved selection, read relevant evidence, and prepare concise context for the task. A connection-information operation makes the active permission understandable to the client.
The final API reference will define routes, method names, request fields and limits. At the product level, an integration needs to communicate:
| Request detail | Why it matters |
|---|---|
| The question or task | Helps return relevant material rather than a general biography. |
| The authorized selection | Keeps the operation within the person's grant. |
| Any supported date or content filter | Distinguishes a current decision from historical material. |
| The desired amount of context | Keeps responses useful and proportionate to the task. |
A filter narrows access; it must never expand it. If a request cannot be answered from the approved material, your application should explain the gap or ask the person whether they want to share something else.
Illustrative context data
The following is a proposed illustration of the information a context response could contain. It is synthetic and is not a callable API example or a published schema. Do not generate a client from it.
{
"snapshot_at": "2026-10-28T10:00:00Z",
"items": [
{
"text": "The project review is planned for Friday.",
"status": "user_confirmed",
"valid_from": "2026-10-27",
"source_ids": ["example-source-7"]
}
],
"sources": [
{
"id": "example-source-7",
"title": "Project review note",
"recorded_at": "2026-10-27T15:00:00Z",
"excerpt": "Move the project review to Friday.",
"version": 2
}
],
"coverage": {
"selection": "approved_project_collection",
"partial": false
}
}
The important relationship is between the statement, its status and its evidence. Preserve that relationship when displaying, transforming or caching the result. A bare sentence loses the distinction between an original statement, an inference and a fact the person has confirmed.
Dates also carry different meanings. In this illustration, snapshot_at records when the response was assembled; it does not establish that every source is fresh, complete or recently synchronized. The date of an event, the date of a document and the time of retrieval are not interchangeable. An undated source should remain undated rather than acquiring an invented timestamp in your interface.
Provenance, freshness and coverage
Give people a way to inspect the sources behind an answer. Use the authenticated source references provided by the integration; do not turn a protected source into a public download link.
Display incomplete or conflicting evidence honestly. “No matching record in the selected collection” is different from “this never happened.” An import may preserve a file before its contents are ready for retrieval, and an archive may omit material the original provider does not export.
When a user corrects information, request current context before using it for a new result. Retain source versions and retrieval time where the published contract provides them. Do not treat a previously fetched profile as permanently current.
Your application must also respect changes to sharing permission. A summary derived from several records is still connected to those sources. If some cease to be authorized, revalidate the summary before further use or display under the connection.
Handle corrections without rewriting the person
An application may detect a discrepancy: the source says Thursday, but the user now says Friday. Keep the new statement and its evidence distinguishable from the old record.
The intended write model is a reviewable proposal. The person can accept, edit or reject a suggested memory or correction through the supported SEED experience. Your application's generated text should not silently become a confirmed fact about them.
Preserved originals, editable interpretations and sharing permissions are separate layers. A successful read does not authorize a write, an export, a new recipient or an action in the person's name. The exact availability of proposal operations belongs in the versioned API reference.
Recover from failures
Build recovery around the reason a request could not complete. These are situations to handle, not a list of published SEED error codes.
| Situation | Integration behavior |
|---|---|
| Credentials have expired. | Use the documented renewal or reconnection flow. Preserve the person's selection. |
| Access was revoked. | Stop retrieval and explain that the connection must be authorized again before continuing. |
| The operation or material is outside the grant. | Do not retry with broader identifiers or filters. Offer a user-controlled sharing choice where supported. |
| No relevant evidence is available. | Return an honest empty or insufficient-evidence result. Invite a more precise question or another user-selected source. |
| Processing is incomplete. | Show the available status and follow the documented retry guidance. |
| A source is deleted, changed or no longer shared. | Refresh the evidence and update dependent results instead of hiding the missing source. |
| Usage is limited or the service is temporarily unavailable. | Use bounded retries and the server's documented delay guidance. Avoid an unbounded agent loop. |
| A future write request has an uncertain outcome. | Check its documented operation status before resubmitting. Do not assume a timeout means nothing happened. |
Keep operational logs useful without copying the personal payload. Record request identifiers where available, timing, outcome and the operation being attempted. Redact credentials; avoid routinely logging questions, excerpts or complete responses.
Cache with permission in mind
Cache only when the published contract permits it. Separate caches by the authorized account, application and selection; do not use a shared semantic cache that could return one person's context to another.
Treat cached content as a copy of personal data with its own retention obligations. Permission expiry, revocation, source deletion and a confirmed correction can each affect whether that copy remains appropriate to use. Define a refresh and deletion policy before relying on cached results.
An expiry on API access does not remotely erase data your application has already received. Explain your retention and deletion behavior to the person alongside the SEED authorization experience.
Prepare for a reliable integration
Before making your integration available to users, exercise the complete journey with synthetic records:
- Authorize a small collection and retrieve an answer supported by its sources.
- Try an unrelated collection and another account's record identifier; ensure neither content nor private metadata is disclosed.
- Correct a fact in SEED and verify that a new request uses the reviewed version.
- Remove a source and check the handling of summaries and citations that depended on it.
- Expire or revoke access, including while a request is pending, and verify the recovery flow.
- Check your logs, caches and support tooling for personal content and credentials.
Use the version and limits published for your access environment. Pin the API contract your client supports and review changes before adopting a new version. A successful HTTP request is only one part of the journey; the resulting answer, permission boundaries and recovery behavior matter too.
Where processing happens
SEED operates the core intelligence that organizes and interprets the vault on its own infrastructure. An API response is a deliberate transfer of the selected context to your application. If your app sends that response to another AI provider, that processing must be part of the disclosed and authorized use.
Source-service conditions and recipient-platform rules can limit which records or uses are eligible. Start with a clear data selection and a clear destination. Access to personal context does not include permission to advertise against it, resell it or impersonate the person.
Review permissions and privacy · Connect through MCP · Explore the integrations · Join the waitlist