# WEDNESDAY Developer Platform — consolidated public documentation

Canonical origin: https://docs.wednesdaychat.com

This file consolidates the human-facing public documentation that is safe to use as a WEDNESDAY platform reference. The HTML pages remain authoritative for navigation and release status.



---

# Search
Source: https://docs.wednesdaychat.com/search/

<h1 id="search">Search</h1>

<p class="lead">Search is a server-owned, account-scoped operation over durable WEDNESDAY state. It is separate from model web search.</p>

<h2 id="global-search">Global search</h2>

<div class="endpoint"><div class="endpoint-head"><span class="method">GET</span><span class="endpoint-path">/search</span></div><div class="endpoint-body"><p>Search the authenticated account's durable search surface.</p></div></div>

<p>The verified query contract uses:</p>

<table>
  <thead>
    <tr>
      <th>Parameter</th>
      <th>Constraint</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">q</code></td>
      <td>Required; 1–160 characters</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">limit</code></td>
      <td>1–100; default 25</td>
    </tr>
  </tbody>
</table>

<p>Results are returned with <code class="language-plaintext highlighter-rouge">Cache-Control: no-store</code>.</p>

<h2 id="project-search">Project search</h2>

<div class="endpoint"><div class="endpoint-head"><span class="method">GET</span><span class="endpoint-path">/projects/{project_id}/search</span></div><div class="endpoint-body"><p>Search within an account-owned project, including a bounded filter and result limit.</p></div></div>

<h2 id="rate-limits-and-errors">Rate limits and errors</h2>

<p>Search can return:</p>

<ul>
  <li><code class="language-plaintext highlighter-rouge">422</code> for an invalid query contract;</li>
  <li><code class="language-plaintext highlighter-rouge">429</code> when the search protection limit is exceeded;</li>
  <li><code class="language-plaintext highlighter-rouge">503</code> when search storage or protection is unavailable.</li>
</ul>

<h2 id="not-the-same-as-web-search">Not the same as web search</h2>

<p>This page documents product-state search. Model tools that discover or ground information from the public web have a separate execution and security boundary and should not be inferred from <code class="language-plaintext highlighter-rouge">/search</code>.</p>


---

# Tools
Source: https://docs.wednesdaychat.com/tools/

<h1 id="using-tools">Using tools</h1>

<p class="lead">Extend a WEDNESDAY turn with search, files, research, location context, projects, connectors, and other bounded execution capabilities. Tool work is represented as typed runtime state rather than hidden model side effects.</p>

<div class="tool-tabs" role="list" aria-label="Tool families">
<span class="tool-tab active">Search</span><span class="tool-tab">Files</span><span class="tool-tab">Research</span><span class="tool-tab">Projects</span><span class="tool-tab">Connectors</span>
</div>

<div class="language-text highlighter-rouge"><div class="highlight"><pre class="highlight"><code>User request
   ↓
WEDNESDAY runtime
   ↓
Tool start → progress/state → completion
   ↓
Structured result returned to the active turn
</code></pre></div></div>

<h2 id="available-tool-families">Available tool families</h2>

<div class="capability-grid">
  <a class="capability-row" href="/search/"><span class="capability-icon">⌕</span><span><strong>Search and retrieval</strong><small>Search durable WEDNESDAY state and support retrieval-oriented workflows.</small></span></a>
  <a class="capability-row" href="/files/"><span class="capability-icon">▣</span><span><strong>Files and Library</strong><small>Upload, inspect, select, attach, retrieve, and manage account-owned file resources.</small></span></a>
  <a class="capability-row" href="/deep-research/"><span class="capability-icon">✦</span><span><strong>Deep research</strong><small>Track longer-running research work as durable task state rather than a single request.</small></span></a>
  <a class="capability-row" href="/projects/"><span class="capability-icon">◇</span><span><strong>Projects and context</strong><small>Use project instructions, settings, files, conversations, connectors, and work history as scoped context.</small></span></a>
  <a class="capability-row" href="/integrations/"><span class="capability-icon">↗</span><span><strong>Connectors</strong><small>Work with explicitly authorized external resources while preserving connector scope and approval boundaries.</small></span></a>
  <a class="capability-row" href="/platform/"><span class="capability-icon">◎</span><span><strong>Location and place context</strong><small>Use location preferences and place-enrichment capabilities where the product flow authorizes them.</small></span></a>
</div>

<h2 id="tool-lifecycle">Tool lifecycle</h2>

<p>The live stream protocol can represent tool start, progress, state transition, and completion events. Stable turn, part, and tool hierarchy identifiers let a client render nested or parallel work without inferring execution state from prose.</p>

<h2 id="authority-and-approvals">Authority and approvals</h2>

<p>Tool availability never implies unlimited authority. File operations remain account-scoped, connector operations remain connector-scoped, public-network access is bounded by runtime policy, and risky external actions can require explicit approval before execution.</p>

<h2 id="failure-handling">Failure handling</h2>

<p>A tool result can fail independently of the surrounding model turn. Clients should preserve tool state, surface meaningful failures, and avoid rewriting a failed execution as if the model merely “changed its mind.”</p>

<h2 id="public-capability-policy">Public capability policy</h2>

<p>A tool becomes a supported developer capability only when its public name, inputs, outputs, authority requirements, failure behavior, and lifecycle are stable enough to depend on.</p>

<div class="notice">Internal tool kinds, telemetry labels, and implementation-specific execution modules are not automatically public developer tools.</div>


---

# Deprecations
Source: https://docs.wednesdaychat.com/deprecations/

<h1 id="deprecations">Deprecations</h1>

<p class="lead">This page is the canonical public index for WEDNESDAY deprecation notices that affect documented contracts.</p>

<h2 id="current-notices">Current notices</h2>

<p>There are no public deprecation notices recorded in this documentation repository at this time.</p>

<p>When a deprecation is published, the notice should identify the affected contract, announcement date, replacement path, migration guidance, and retirement date when one has been committed.</p>


---

# Changelog
Source: https://docs.wednesdaychat.com/changelog/

<h1 id="changelog">Changelog</h1>

<h2 id="september-14-2026">September 14, 2026</h2>

<h3 id="documentation-infrastructure">Documentation infrastructure</h3>

<ul>
  <li>Established <code class="language-plaintext highlighter-rouge">docs.wednesdaychat.com</code> on GitHub Pages.</li>
  <li>Configured the custom domain and enforced HTTPS.</li>
  <li>Established <code class="language-plaintext highlighter-rouge">main</code> as the production documentation branch.</li>
  <li>Added the initial public documentation architecture and machine-readable discovery files.</li>
</ul>

<p>Platform feature changes will be listed here only when verified against the relevant production contract.</p>


---

# Privacy
Source: https://docs.wednesdaychat.com/privacy/

<h1 id="privacy">Privacy</h1>

<p class="lead">WEDNESDAY scopes durable product data to the authorized account and documents privacy-relevant behavior only where it is a stable public contract.</p>

<h2 id="account-scoped-state">Account-scoped state</h2>

<p>Projects, conversations, files, search results, feedback, research state, and related durable records are resolved through the authorized account boundary. Public share links are a deliberate exception: they expose only the share target represented by the generated share token.</p>

<h2 id="data-minimization">Data minimization</h2>

<p>Clients should send only the information required for the requested workflow. Do not place secrets, credentials, or unrelated personal data into prompts, project instructions, file metadata, tool arguments, logs, or public share links.</p>

<h2 id="files-and-connectors">Files and connectors</h2>

<p>Files and connector-backed resources remain subject to owner and connector scope. Applications should preserve the user’s authorization boundary when displaying, caching, exporting, or acting on retrieved data.</p>

<h2 id="public-documentation">Public documentation</h2>

<p>This public documentation intentionally excludes secret configuration, internal endpoints, private deployment topology, incident procedures, privileged administration behavior, and implementation details that would unnecessarily expand the public data surface.</p>

<h2 id="product-policy">Product policy</h2>

<div class="notice">This developer page describes technical privacy boundaries, not the full WEDNESDAY consumer privacy policy or legal terms. Product-facing privacy notices remain authoritative for legal disclosures and user rights.</div>


---

# Projects
Source: https://docs.wednesdaychat.com/projects/

<h1 id="projects">Projects</h1>

<p class="lead">Projects group durable conversations and project-scoped context under the authenticated WEDNESDAY account.</p>

<h2 id="project-lifecycle">Project lifecycle</h2>

<p>The production API supports listing, reading, creating, renaming, archiving, deleting, and restoring projects.</p>

<table>
  <thead>
    <tr>
      <th>Method</th>
      <th>Route</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">GET</code></td>
      <td><code class="language-plaintext highlighter-rouge">/projects</code></td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">POST</code></td>
      <td><code class="language-plaintext highlighter-rouge">/projects</code></td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">GET</code></td>
      <td><code class="language-plaintext highlighter-rouge">/projects/{project_id}</code></td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">PUT</code></td>
      <td><code class="language-plaintext highlighter-rouge">/projects/{project_id}/name</code></td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">PUT</code></td>
      <td><code class="language-plaintext highlighter-rouge">/projects/{project_id}/archive</code></td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">DELETE</code></td>
      <td><code class="language-plaintext highlighter-rouge">/projects/{project_id}</code></td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">POST</code></td>
      <td><code class="language-plaintext highlighter-rouge">/projects/{project_id}/restore</code></td>
    </tr>
  </tbody>
</table>

<h2 id="project-context">Project context</h2>

<p>A project can expose account-owned settings and instructions through dedicated read/write routes. Chat execution can load project context for a conversation and render that context into the turn’s system context.</p>

<h2 id="search-and-resources">Search and resources</h2>

<p>Projects have production routes for:</p>

<ul>
  <li>project-scoped search;</li>
  <li>instructions and settings;</li>
  <li>connector bindings;</li>
  <li>work history;</li>
  <li>file membership;</li>
  <li>project-owned conversation listing and creation.</li>
</ul>

<h2 id="ownership-boundary">Ownership boundary</h2>

<p>Every project operation in this guide is session-protected. The project ID selects a resource <strong>within</strong> the authenticated account; it does not select the account itself.</p>

<h2 id="conflicts-and-deletion">Conflicts and deletion</h2>

<p>Mutating operations may return <code class="language-plaintext highlighter-rouge">409 Conflict</code> when state has changed or an explicit confirmation requirement is not satisfied. Clients should not collapse those outcomes into a generic retry loop.</p>


---

# Agents
Source: https://docs.wednesdaychat.com/agents/

<h1 id="agents">Agents</h1>

<p class="lead">WEDNESDAY agent behavior is built from stateful turns, typed tool activity, durable task state, and explicit user control rather than a hidden autonomous loop.</p>

<h2 id="stateful-execution">Stateful execution</h2>

<p>A turn belongs to authenticated durable conversation state. Project context can be loaded for the conversation before execution and rendered into the system context supplied to the turn.</p>

<h2 id="observable-activity">Observable activity</h2>

<p>The stream protocol has distinct activity and tool event families. Tool execution can report start, progress, state transitions, and completion rather than collapsing all tool work into opaque text.</p>

<h2 id="steering-and-cancellation">Steering and cancellation</h2>

<p>Supported turns can accept mid-turn steering while the acceptance window remains open. Durable research tasks have an explicit cancellation route.</p>

<h2 id="approval-aware-behavior">Approval-aware behavior</h2>

<p>The execution protocol models approval risk and reversibility as explicit concepts. Public documentation will describe concrete approval flows only when the corresponding user/developer contract is stable.</p>

<h2 id="agent-boundary">Agent boundary</h2>

<p>An agent may use tools and durable state, but authorization remains server-owned. Agent execution does not bypass the account session, project ownership, file ownership, connector scope, or external-write approval boundaries.</p>


---

# Reliability
Source: https://docs.wednesdaychat.com/reliability/

<h1 id="reliability">Reliability</h1>

<p class="lead">Reliability documentation explains externally observable behavior: availability, retries, timeouts, idempotency, degradation, and status communication where those contracts are publicly defined.</p>

<h2 id="status-information">Status information</h2>

<p>Live operational status belongs on the independent WEDNESDAY status service rather than being hard-coded into documentation pages. Documentation should explain behavior; the status service should report current incidents and availability.</p>

<h2 id="failure-semantics">Failure semantics</h2>

<p>API and tool references should document actionable error behavior close to the affected contract so developers do not have to infer retry or recovery behavior.</p>


---

# Learn
Source: https://docs.wednesdaychat.com/learn/

<h1 id="get-inspired-and-build">Get inspired and build</h1>

<p class="lead">Use focused learning paths to move from platform fundamentals to production WEDNESDAY applications.</p>

<h2 id="learning-tracks">Learning tracks</h2>

<div class="grid">
<a class="card" href="/agents/"><div class="card-title">Building agents</div><div class="card-copy">Understand tool execution, project context, approvals, durable work, and runtime state.</div></a>
<a class="card" href="/getting-started/"><div class="card-title">AI app development</div><div class="card-copy">Start with the production boundary, session authority, streaming, and durable application state.</div></a>
<a class="card" href="/models/"><div class="card-title">Model routing</div><div class="card-copy">Choose WEDNESDAY execution profiles without coupling your application to private provider routing.</div></a>
<a class="card" href="/production/"><div class="card-title">Production readiness</div><div class="card-copy">Design retries, state reconciliation, security boundaries, readiness checks, and release controls.</div></a>
</div>

<h2 id="explore-by-topic">Explore by topic</h2>

<div class="capability-grid">
<a class="capability-row" href="/tools/"><span class="capability-icon">✦</span><span><strong>Tools</strong><small>Search, files, research, projects, connectors, and bounded external execution.</small></span></a>
<a class="capability-row" href="/platform/streaming/"><span class="capability-icon">⌁</span><span><strong>Streaming</strong><small>Build UIs around structured incremental model and tool events.</small></span></a>
<a class="capability-row" href="/files/"><span class="capability-icon">▣</span><span><strong>Files</strong><small>Work with uploads, Library state, attachments, and account-owned file resources.</small></span></a>
<a class="capability-row" href="/integrations/"><span class="capability-icon">↗</span><span><strong>Integrations</strong><small>Connect authorized external resources while preserving scope and approval boundaries.</small></span></a>
<a class="capability-row" href="/api/reference/"><span class="capability-icon">{ }</span><span><strong>API reference</strong><small>Browse the deliberately published production HTTP surface.</small></span></a>
<a class="capability-row" href="/machine-readable/"><span class="capability-icon">≡</span><span><strong>Docs for agents</strong><small>Use Markdown twins, <code>llms.txt</code>, the consolidated corpus, and search index.</small></span></a>
</div>

<h2 id="keep-current">Keep current</h2>

<p>Use the <a href="/changelog/">Changelog</a> for public documentation and platform changes, <a href="/deprecations/">Deprecations</a> for migration-sensitive changes, and <a href="https://status.wednesdaychat.com">WEDNESDAY Status</a> for operational availability.</p>


---

# Authentication
Source: https://docs.wednesdaychat.com/api/authentication/

<h1 id="authentication">Authentication</h1>

<p class="lead">WEDNESDAY production requests are authorized through the account session boundary used by the WEDNESDAY product. Durable ownership is derived server-side from that authorized session.</p>

<h2 id="account-authority">Account authority</h2>

<p>For protected operations, the API resolves the account owner from the authorized server session rather than trusting a caller-supplied owner identifier. This keeps projects, conversations, files, search results, and durable chat state scoped to the authenticated account.</p>

<h2 id="browser-requests">Browser requests</h2>

<p>The production web application communicates with <code>https://api.wednesdaychat.com</code> using the WEDNESDAY session boundary. Cross-origin access is restricted to approved WEDNESDAY origins and explicitly allowed methods and headers.</p>

<h2 id="request-headers">Request headers</h2>

<p>Some production flows use WEDNESDAY-specific headers for session continuity, CSRF protection, client identity, idempotency, or turn coordination. A header appearing in the service implementation does not by itself make it a public third-party authentication mechanism.</p>

<h2 id="third-party-developer-access">Third-party developer access</h2>

<div class="notice"><strong>No implied API-key program.</strong> WEDNESDAY does not document a general public API-key authentication contract until that contract is explicitly released. Do not attempt to synthesize account/session headers or rely on internal browser-session behavior from an external integration.</div>

<h2 id="authorization-failures">Authorization failures</h2>

<p>Callers should treat authorization and session failures as terminal for the current credential context and re-establish a valid WEDNESDAY session through the supported product flow rather than retrying with fabricated identity data.</p>


---

# API reference
Source: https://docs.wednesdaychat.com/api/reference/

<h1 id="api-reference">API reference</h1>

<p class="lead">The production API origin is <code>https://api.wednesdaychat.com</code>. This reference documents only routes and behaviors that are verified in the production service and safe to publish.</p>

<div class="notice"><strong>Access boundary:</strong> WEDNESDAY currently uses server-authorized account sessions for most product operations. The existence of an HTTP route does not imply an unrestricted third-party API-key contract.</div>

<h2 id="system">System</h2>

<div class="endpoint"><div class="endpoint-head"><span class="method">GET</span><span class="endpoint-path">/health</span></div><div class="endpoint-body"><p>Lightweight service health probe. Returns an <code>ok</code> health status when the API process is available.</p></div></div>

<div class="endpoint"><div class="endpoint-head"><span class="method">GET</span><span class="endpoint-path">/ready</span></div><div class="endpoint-body"><p>Production readiness probe. Readiness depends on required backing services including persistence, cache, object storage, malware scanning, and model access.</p></div></div>

<div class="endpoint"><div class="endpoint-head"><span class="method">GET</span><span class="endpoint-path">/version</span></div><div class="endpoint-body"><p>Returns the WEDNESDAY API service identity, environment, build SHA when available, and configured model-provider family. The response is marked <code>no-store</code>.</p></div></div>

<h2 id="search">Search</h2>

<div class="endpoint"><div class="endpoint-head"><span class="method">GET</span><span class="endpoint-path">/search?q=…</span></div><div class="endpoint-body"><p>Searches durable account-owned WEDNESDAY state. Query text is required and bounded; result size is bounded by the service.</p></div></div>

<h2 id="projects">Projects</h2>

<p>Verified project operations include listing, creating, loading, renaming, archiving, restoring, and deleting projects; reading and updating project settings and instructions; project search; project conversations; file membership; connector bindings; and work history.</p>

<h2 id="conversations">Conversations</h2>

<p>Verified conversation operations include listing and loading conversations, messages, drafts, follow-ups, branches, archive state, pin state, project movement, feedback, sharing, usage recording, and durable deletion.</p>

<h2 id="chat-streaming">Chat streaming</h2>

<div class="endpoint"><div class="endpoint-head"><span class="method post">POST</span><span class="endpoint-path">/chat</span></div><div class="endpoint-body"><p>Starts a durable streaming chat turn for the authorized account. The stream is explicitly non-cacheable and supports structured runtime events.</p></div></div>

<div class="endpoint"><div class="endpoint-head"><span class="method post">POST</span><span class="endpoint-path">/chat/{turn_id}/input</span></div><div class="endpoint-body"><p>Submits mid-turn steering input to an active turn. Durable cancellation is supported when the turn identifier resolves to a durable chat turn.</p></div></div>

<h2 id="files-and-artifacts">Files and artifacts</h2>

<p>The production service exposes owner-scoped file upload, file inspection, file-library, picker, attachment-state, download, message-attachment, assistant-artifact, location-context, memory-source-consent, and deep-research routers. Individual contracts are published only after their request/response schemas are stable enough to support externally.</p>

<h2 id="contract-policy">Contract policy</h2>

<p>Routes used only for internal operations, provider callbacks, privileged administration, deployment, or implementation-specific coordination are intentionally omitted. Public documentation is a compatibility promise; source-code presence alone is not.</p>


---

# Errors
Source: https://docs.wednesdaychat.com/api/errors/

<h1 id="errors">Errors</h1>

<p class="lead">WEDNESDAY uses standard HTTP status codes plus concise error detail strings. Clients should branch on status and documented semantics rather than parsing incidental implementation text.</p>

<h2 id="common-status-codes">Common status codes</h2>

<table>
  <thead>
    <tr>
      <th>Status</th>
      <th>Meaning</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">400</code></td>
      <td>Invalid request shape or transport constraint.</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">404</code></td>
      <td>Requested account-owned resource or share target was not found.</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">409</code></td>
      <td>The requested state transition conflicts with current durable state.</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">410</code></td>
      <td>A time-bounded resource, such as an upload session, has expired.</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">413</code></td>
      <td>A request body exceeds the accepted size.</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">415</code></td>
      <td>An uploaded media type or content representation is unsupported.</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">422</code></td>
      <td>A validated parameter or identifier is semantically invalid.</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">429</code></td>
      <td>A rate limit was exceeded. Respect <code class="language-plaintext highlighter-rouge">Retry-After</code> when supplied.</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">503</code></td>
      <td>A required WEDNESDAY dependency or protection layer is unavailable.</td>
    </tr>
  </tbody>
</table>

<h2 id="retry-behavior">Retry behavior</h2>

<p>Retry only when the failure class is plausibly transient. <code class="language-plaintext highlighter-rouge">429</code> responses may include a <code class="language-plaintext highlighter-rouge">Retry-After</code> header and should not be retried before that delay. <code class="language-plaintext highlighter-rouge">503</code> can indicate unavailable persistence, cache, model access, storage, protection, or other required platform dependencies.</p>

<p>Do not automatically retry <code class="language-plaintext highlighter-rouge">400</code>, <code class="language-plaintext highlighter-rouge">404</code>, <code class="language-plaintext highlighter-rouge">409</code>, <code class="language-plaintext highlighter-rouge">410</code>, <code class="language-plaintext highlighter-rouge">413</code>, <code class="language-plaintext highlighter-rouge">415</code>, or <code class="language-plaintext highlighter-rouge">422</code> without changing the request or reconciling state.</p>

<h2 id="durable-conflicts">Durable conflicts</h2>

<p>A <code class="language-plaintext highlighter-rouge">409</code> response is meaningful platform state, not a generic transport failure. Examples include trying to mutate a resource after its state has moved on or submitting steering after a turn is no longer accepting input.</p>

<h2 id="error-text">Error text</h2>

<div class="notice">Error detail strings are intended for diagnostics, but clients should not treat undocumented wording as a stable machine contract. Stable client behavior should key off HTTP status and fields explicitly documented for the endpoint.</div>


---

# Rate limits
Source: https://docs.wednesdaychat.com/api/rate-limits/

<h1 id="rate-limits">Rate limits</h1>

<p class="lead">WEDNESDAY applies protection at the production service boundary. Chat and durable-state operations use dedicated rate-limit paths, and the platform can fail closed when protection infrastructure is unavailable.</p>

<h2 id="what-is-limited">What is limited</h2>

<p>Verified production code applies rate-limit enforcement to chat traffic and to conversation-oriented persistence flows used by search, projects, files, feedback, sharing, and related durable operations.</p>

<h2 id="429-too-many-requests"><code class="language-plaintext highlighter-rouge">429 Too Many Requests</code></h2>

<p>When a limit is exceeded, the API returns <code class="language-plaintext highlighter-rouge">429</code>. Where available, the response includes <code class="language-plaintext highlighter-rouge">Retry-After</code> with the number of seconds a client should wait before retrying.</p>

<div class="language-http highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="k">HTTP</span><span class="o">/</span><span class="m">1.1</span> <span class="m">429</span> <span class="ne">Too Many Requests</span>
<span class="na">Retry-After</span><span class="p">:</span> <span class="s">12</span>
<span class="na">Content-Type</span><span class="p">:</span> <span class="s">application/json</span>
</code></pre></div></div>

<h2 id="protection-availability">Protection availability</h2>

<p>WEDNESDAY does not silently bypass protection when its rate-limit layer cannot make a trustworthy decision. A protection dependency failure can surface as <code class="language-plaintext highlighter-rouge">503 Service Unavailable</code> instead of allowing unprotected traffic.</p>

<h2 id="published-quotas">Published quotas</h2>

<div class="notice"><strong>No invented quotas.</strong> Numeric request-per-minute or token quotas are not published until they are a stable product contract. Clients should implement backoff for `429` independently of any assumed quota.</div>

<h2 id="client-guidance">Client guidance</h2>

<p>Use bounded exponential backoff, honor <code class="language-plaintext highlighter-rouge">Retry-After</code>, avoid retry storms, and keep idempotent operations safe to replay where the endpoint contract allows it. For state-changing requests, reconcile the durable result before blindly retrying after network uncertainty.</p>


---

# API
Source: https://docs.wednesdaychat.com/api/

<h1 id="api">API</h1>

<p class="lead">WEDNESDAY exposes a production HTTP service at <code>https://api.wednesdaychat.com</code>. This documentation publishes the supported external contract without treating every internal service route as public API.</p>

<h2 id="production-origin">Production origin</h2>

<div class="language-text highlighter-rouge"><div class="highlight"><pre class="highlight"><code>https://api.wednesdaychat.com
</code></pre></div></div>

<p>The web product and supported WEDNESDAY clients use this origin for durable product operations. The API is designed around account-authorized state, streaming execution, projects, files, search, research, sharing, and related platform workflows.</p>

<h2 id="access-model">Access model</h2>

<p>Most product operations require a valid WEDNESDAY account session and derive durable ownership from server-authorized account state. Do not fabricate owner identifiers or infer a general third-party API-key program from browser/client transport details.</p>

<p>Start with <a href="/api/authentication/">Authentication</a> before integrating a protected route.</p>

<h2 id="reference">Reference</h2>

<p>Use the <a href="/api/reference/">API reference</a> for the deliberately published HTTP surface. The reference currently includes verified system, search, project, conversation, chat, file, and artifact capability boundaries while withholding privileged, provider-callback, administrative, and implementation-only routes.</p>

<h2 id="errors-and-protection">Errors and protection</h2>

<ul>
  <li><a href="/api/errors/">Errors</a> documents stable HTTP failure classes and retry guidance.</li>
  <li><a href="/api/rate-limits/">Rate limits</a> documents <code class="language-plaintext highlighter-rouge">429</code>, <code class="language-plaintext highlighter-rouge">Retry-After</code>, fail-closed protection, and quota publication policy.</li>
  <li><a href="/production/">Production best practices</a> covers durable-state reconciliation, streaming, readiness, security, and release discipline.</li>
</ul>

<h2 id="contract-policy">Contract policy</h2>

<p>Public documentation is a compatibility promise. An endpoint, header, provider model, internal module, or telemetry label found in source code is <strong>not</strong> automatically public API. WEDNESDAY publishes only the behavior it intends developers to depend on.</p>

<div class="notice"><strong>Machine-readable docs:</strong> use <a href="/llms.txt"><code>/llms.txt</code></a> for routing, <a href="/llms-full.txt"><code>/llms-full.txt</code></a> for the consolidated corpus, and Markdown twins linked from individual reference pages.</div>


---

# Streaming
Source: https://docs.wednesdaychat.com/platform/streaming/

<h1 id="streaming">Streaming</h1>

<p class="lead">Live chat uses Server-Sent Events with a versioned, ordered event protocol rather than an unstructured text socket.</p>

<h2 id="transport">Transport</h2>

<p><code class="language-plaintext highlighter-rouge">POST /chat</code> returns:</p>

<div class="language-text highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Content-Type: text/event-stream
Cache-Control: no-cache, no-transform
X-Accel-Buffering: no
</code></pre></div></div>

<p>The route requires an authenticated account session and is protected by the chat rate limiter.</p>

<h2 id="protocol-version">Protocol version</h2>

<p>Current stream events carry <code class="language-plaintext highlighter-rouge">protocol_version: 1</code>, a turn identifier, and a monotonically ordered sequence field. Part-level events add a part identifier; tool events add a tool identifier.</p>

<p>Clients should treat the protocol version as part of the compatibility contract rather than assuming event payloads can change without coordination.</p>

<h2 id="event-families">Event families</h2>

<p>The current stream model includes typed events for:</p>

<ul>
  <li>turn start and routing;</li>
  <li>activity progress;</li>
  <li>answer start, delta, and completion;</li>
  <li>code start, delta, and completion;</li>
  <li>tool start, progress, state transitions, and completion;</li>
  <li>additional bounded platform events as documented by their public contract.</li>
</ul>

<h2 id="backpressure-and-intermediaries">Backpressure and intermediaries</h2>

<p>The API disables response buffering and transformation for the stream. Clients should consume events incrementally and should not depend on intermediaries coalescing chunks.</p>

<h2 id="durable-state-is-separate">Durable state is separate</h2>

<p>Streaming transports live execution. Conversation persistence is a separate durable boundary. A robust client should not assume that the presence or absence of one network chunk is itself the durable conversation record.</p>


---

# Conversation state
Source: https://docs.wednesdaychat.com/platform/conversation-state/

<h1 id="conversation-state">Conversation state</h1>

<p class="lead">Conversation state is a durable server-owned resource. It is scoped to the authenticated account and remains separate from the transport of a single live model response.</p>

<h2 id="core-routes">Core routes</h2>

<table>
  <thead>
    <tr>
      <th>Method</th>
      <th>Route</th>
      <th>Purpose</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">GET</code></td>
      <td><code class="language-plaintext highlighter-rouge">/conversations</code></td>
      <td>List account-owned conversations with cursor pagination</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">GET</code></td>
      <td><code class="language-plaintext highlighter-rouge">/conversations/{conversation_id}</code></td>
      <td>Load one conversation</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">PUT</code></td>
      <td><code class="language-plaintext highlighter-rouge">/conversations/{conversation_id}</code></td>
      <td>Persist a conversation write</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">PUT</code></td>
      <td><code class="language-plaintext highlighter-rouge">/conversations/{conversation_id}/title</code></td>
      <td>Update the title</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">GET</code></td>
      <td><code class="language-plaintext highlighter-rouge">/conversations/{conversation_id}/messages</code></td>
      <td>Page through messages</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">PUT</code></td>
      <td><code class="language-plaintext highlighter-rouge">/conversations/{conversation_id}/draft</code></td>
      <td>Persist the composer draft</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">DELETE</code></td>
      <td><code class="language-plaintext highlighter-rouge">/conversations/{conversation_id}</code></td>
      <td>Delete the conversation</td>
    </tr>
  </tbody>
</table>

<p>All routes in this table require the validated WEDNESDAY account session.</p>

<h2 id="follow-ups-and-branches">Follow-ups and branches</h2>

<p>The API supports queued follow-ups, follow-up reordering and state changes, creation of conversation branches from a message, and switching the active branch.</p>

<p>Branch operations remain conversation-owner scoped. A client cannot select another account’s durable owner by supplying an owner identifier.</p>

<h2 id="organization-state">Organization state</h2>

<p>Conversation records can be archived, pinned, and moved into or out of projects. Project-move targets are returned from an owner-scoped route so the client does not need to infer allowed destinations.</p>

<h2 id="feedback-and-sharing">Feedback and sharing</h2>

<p>Feedback is stored against the latest eligible response in the conversation. Share creation is session-protected, while resolution of a valid share token is part of the intentionally public surface.</p>

<h2 id="consistency-behavior">Consistency behavior</h2>

<p>The persistence layer distinguishes missing resources, conflicts, rate limits, and temporary store failures. Clients should handle <code class="language-plaintext highlighter-rouge">404</code>, <code class="language-plaintext highlighter-rouge">409</code>, <code class="language-plaintext highlighter-rouge">429</code>, and <code class="language-plaintext highlighter-rouge">503</code> as distinct states rather than retrying every failure identically.</p>


---

# Mid-turn steering
Source: https://docs.wednesdaychat.com/platform/steering/

<h1 id="mid-turn-steering">Mid-turn steering</h1>

<p class="lead">WEDNESDAY can accept supported input during a running turn instead of forcing every correction into a brand-new conversation turn.</p>

<h2 id="endpoint">Endpoint</h2>

<div class="endpoint"><div class="endpoint-head"><span class="method post">POST</span><span class="endpoint-path">/chat/{turn_id}/input</span></div><div class="endpoint-body"><p>Submit a validated steering payload to an active turn. Successful submission returns HTTP <code>202</code>.</p></div></div>

<p>The operation is account-session protected and uses the same chat-rate-limit boundary as the live chat route.</p>

<h2 id="acceptance-window">Acceptance window</h2>

<p>Steering is not guaranteed after a turn stops accepting input. When the transport can no longer deliver steering, the API returns <code class="language-plaintext highlighter-rouge">409 Conflict</code> rather than acknowledging input that was not applied.</p>

<h2 id="cancellation">Cancellation</h2>

<p>Supported steering payloads can represent durable turn cancellation. Cancellation validates the durable turn identifier and persists the cancel request before the turn is treated as cancelled.</p>

<h2 id="error-behavior">Error behavior</h2>

<ul>
  <li><code class="language-plaintext highlighter-rouge">404</code> — the durable turn does not exist for the account.</li>
  <li><code class="language-plaintext highlighter-rouge">409</code> — the turn is no longer accepting steering.</li>
  <li><code class="language-plaintext highlighter-rouge">422</code> — the cancellation form contains an invalid durable turn identifier.</li>
  <li><code class="language-plaintext highlighter-rouge">429</code> — the chat rate limit is exceeded.</li>
  <li><code class="language-plaintext highlighter-rouge">503</code> — steering transport, cancellation persistence, or rate-limit protection is unavailable.</li>
</ul>

<p>Clients should surface these outcomes distinctly; a <code class="language-plaintext highlighter-rouge">409</code> is a lifecycle outcome, not a generic server failure.</p>


---

# Key concepts
Source: https://docs.wednesdaychat.com/platform/

<h1 id="key-concepts">Key concepts</h1>

<p class="lead">WEDNESDAY combines server-owned identity, durable conversation state, structured streaming, project context, and tool-oriented execution into one product runtime.</p>

<h2 id="server-authoritative-identity">Server-authoritative identity</h2>

<p>Protected operations derive the durable account owner from the validated server session. Client-supplied owner or role claims are not the authority boundary.</p>

<p>This design keeps conversation, project, file, search, feedback, and tool state consistently scoped to the authenticated account.</p>

<h2 id="durable-conversations">Durable conversations</h2>

<p>Conversation records are persisted independently of the live model stream. The platform supports conversation listing and loading, messages, drafts, follow-ups, branches, archive state, pinning, project movement, feedback, sharing, usage records, and deletion.</p>

<p><a href="/platform/conversation-state/">Read about conversation state →</a></p>

<h2 id="structured-streaming">Structured streaming</h2>

<p>Live chat responses use Server-Sent Events (<code class="language-plaintext highlighter-rouge">text/event-stream</code>) with a versioned event protocol. Events carry ordered sequence numbers and typed state for turns, answers, code, activities, and tools.</p>

<p><a href="/platform/streaming/">Read about streaming →</a></p>

<h2 id="mid-turn-steering">Mid-turn steering</h2>

<p>A running turn can accept supported steering input while it remains steerable. The server rejects steering after the acceptance window closes rather than silently pretending it was applied.</p>

<p><a href="/platform/steering/">Read about steering →</a></p>

<h2 id="projects-and-context">Projects and context</h2>

<p>Projects group conversations and related context. Production routes support project settings, instructions, search, files, connector bindings, work history, and project-scoped conversations.</p>

<p><a href="/projects/">Read about projects →</a></p>

<h2 id="fail-closed-api-surface">Fail-closed API surface</h2>

<p>The production API treats unlisted routes as session-required by default. Only an explicit narrow public allowlist is available without an account session.</p>


---

# Integrations
Source: https://docs.wednesdaychat.com/integrations/

<h1 id="integrations">Integrations</h1>

<p class="lead">Integrations connect WEDNESDAY to external systems without collapsing external authorization into the model or the browser client.</p>

<h2 id="project-connector-bindings">Project connector bindings</h2>

<p>Projects expose an owner-scoped connector-binding view and an explicit unbind operation. A connector binding belongs to the authenticated project/account context; possession of a binding ID alone is not authorization.</p>

<h2 id="github">GitHub</h2>

<p>The production codebase includes GitHub authorization, repository, reference-context, workspace, branch, and patch workflows. GitHub callback/webhook operations are operational integration surfaces and are not interchangeable with user-facing project APIs.</p>

<h2 id="separation-of-concerns">Separation of concerns</h2>

<p>A production integration has multiple independent boundaries:</p>

<ol>
  <li>the WEDNESDAY account session;</li>
  <li>the external provider authorization or installation;</li>
  <li>resource-level scope inside that provider;</li>
  <li>approval requirements for writes or destructive actions.</li>
</ol>

<h2 id="public-integration-contract">Public integration contract</h2>

<p>This documentation publishes integration behavior that users and developers may rely on. It intentionally omits secret handling, private webhook validation details, installation credentials, internal provider tokens, and privileged operational procedures.</p>

<h2 id="revocation">Revocation</h2>

<p>Where the product exposes an unbind or disconnect operation, clients should treat revocation as a first-class lifecycle state rather than assuming access remains valid indefinitely.</p>


---

# Deep research
Source: https://docs.wednesdaychat.com/deep-research/

<h1 id="deep-research">Deep research</h1>

<p class="lead">Deep research work is represented by durable, account-owned task records so longer-running research can be inspected independently of a single browser stream.</p>

<h2 id="task-routes">Task routes</h2>

<table>
  <thead>
    <tr>
      <th>Method</th>
      <th>Route</th>
      <th>Purpose</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">GET</code></td>
      <td><code class="language-plaintext highlighter-rouge">/conversations/{conversation_id}/research-tasks</code></td>
      <td>List research tasks for a conversation</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">GET</code></td>
      <td><code class="language-plaintext highlighter-rouge">/research-tasks/{task_id}</code></td>
      <td>Load one task</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">POST</code></td>
      <td><code class="language-plaintext highlighter-rouge">/research-tasks/{task_id}/cancel</code></td>
      <td>Request cancellation</td>
    </tr>
  </tbody>
</table>

<p>Conversation task listing accepts a bounded <code class="language-plaintext highlighter-rouge">limit</code> from 1 to 100 with a default of 20.</p>

<h2 id="durable-ownership">Durable ownership</h2>

<p>Research tasks are resolved inside the authenticated account boundary. Task and conversation identifiers do not replace session authority.</p>

<h2 id="lifecycle-errors">Lifecycle errors</h2>

<ul>
  <li><code class="language-plaintext highlighter-rouge">404</code> — the task or associated resource is not available to the account.</li>
  <li><code class="language-plaintext highlighter-rouge">409</code> — the requested lifecycle transition conflicts with current task state.</li>
  <li><code class="language-plaintext highlighter-rouge">422</code> — a supplied value violates the public request contract.</li>
  <li><code class="language-plaintext highlighter-rouge">429</code> — the research-work protection limit is exceeded.</li>
  <li><code class="language-plaintext highlighter-rouge">503</code> — task persistence or protection is unavailable.</li>
</ul>

<h2 id="cache-behavior">Cache behavior</h2>

<p>Task reads and cancellation responses are emitted with <code class="language-plaintext highlighter-rouge">Cache-Control: no-store</code> so clients do not reuse stale research state.</p>


---

# Files
Source: https://docs.wednesdaychat.com/files/

<h1 id="files">Files</h1>

<p class="lead">File intake uses an explicit upload-session lifecycle so WEDNESDAY can validate ownership, metadata, transport, content, and storage state before a file becomes usable.</p>

<h2 id="upload-lifecycle">Upload lifecycle</h2>

<p>The production upload flow exposes three core operations:</p>

<table>
  <thead>
    <tr>
      <th>Method</th>
      <th>Route</th>
      <th>Purpose</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">POST</code></td>
      <td><code class="language-plaintext highlighter-rouge">/files/uploads</code></td>
      <td>Initiate an owner-scoped upload session</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">GET</code></td>
      <td><code class="language-plaintext highlighter-rouge">/files/uploads/{upload_id}</code></td>
      <td>Read upload progress and state</td>
    </tr>
    <tr>
      <td><code class="language-plaintext highlighter-rouge">PUT</code></td>
      <td><code class="language-plaintext highlighter-rouge">/files/uploads/{upload_id}/content</code></td>
      <td>Stream the complete file body</td>
    </tr>
  </tbody>
</table>

<p>Upload initiation uses an <code class="language-plaintext highlighter-rouge">Idempotency-Key</code> header so safe retries can refer to the same initiation intent.</p>

<h2 id="transport-rules">Transport rules</h2>

<p>The content upload is intentionally strict:</p>

<ul>
  <li>compressed request bodies are not accepted;</li>
  <li>partial <code class="language-plaintext highlighter-rouge">Content-Range</code> resume is not supported;</li>
  <li>a retry sends the upload body again from byte zero;</li>
  <li>the body media type must match the initiated session or use <code class="language-plaintext highlighter-rouge">application/octet-stream</code>;</li>
  <li>declared and observed size are validated against the session.</li>
</ul>

<h2 id="validation-and-failure-states">Validation and failure states</h2>

<p>The file pipeline distinguishes malformed requests, unsupported media, invalid content, oversized files, expired sessions, missing sources, conflicts, rate limits, and temporary service failures.</p>

<p>Relevant HTTP outcomes include <code class="language-plaintext highlighter-rouge">400</code>, <code class="language-plaintext highlighter-rouge">404</code>, <code class="language-plaintext highlighter-rouge">409</code>, <code class="language-plaintext highlighter-rouge">410</code>, <code class="language-plaintext highlighter-rouge">413</code>, <code class="language-plaintext highlighter-rouge">415</code>, <code class="language-plaintext highlighter-rouge">429</code>, and <code class="language-plaintext highlighter-rouge">503</code>.</p>

<h2 id="library-and-attachments">Library and attachments</h2>

<p>The production file router also supports owner-scoped Library views, file picker results, attachment-state lookup, user-message attachment preparation, and secure file inspection/download paths.</p>

<div class="notice"><strong>Security boundary:</strong> file IDs do not grant authority. File operations are evaluated inside the authenticated account session.</div>


---

# Models
Source: https://docs.wednesdaychat.com/models/

<h1 id="models">Models</h1>

<p class="lead">Choose the execution profile that matches the work. WEDNESDAY owns the routing contract while retaining freedom to improve the underlying provider route as long as the published profile behavior remains compatible.</p>

<h2 id="choose-an-execution-profile">Choose an execution profile</h2>

<div class="model-catalog">
  <article class="model-card model-balanced">
    <div class="model-visual"><span>Balanced</span></div>
    <div class="model-meta"><strong>Balanced</strong><span class="model-badge">Production</span></div>
    <p>Default conversational profile for responsive, general-purpose work with balanced reasoning and latency.</p>
  </article>
  <article class="model-card model-deep">
    <div class="model-visual"><span>Deep</span></div>
    <div class="model-meta"><strong>Deep reasoning</strong><span class="model-badge">Production</span></div>
    <p>Higher-reasoning profile for complex analysis and tasks where depth matters more than minimum latency.</p>
  </article>
  <article class="model-card model-code">
    <div class="model-visual"><span>Code</span></div>
    <div class="model-meta"><strong>Coding</strong><span class="model-badge">Production</span></div>
    <p>Code-oriented execution route used when the runtime classifies the work as software-development heavy.</p>
  </article>
</div>

<div class="notice"><strong>Profile ≠ provider model ID.</strong> WEDNESDAY can change an upstream route without renaming a WEDNESDAY execution profile when the public behavior remains compatible. Upstream provider identifiers are not a permanent developer contract unless explicitly published as one.</div>

<h2 id="routing-is-observable">Routing is observable</h2>

<p>The streaming protocol can represent resolved routing information for a turn, including a model identifier, model role, requested and resolved intelligence level, latency profile, reasoning profile, and bounded completion behavior. Those fields make execution observable; they do not automatically turn every internal route target into a permanently supported developer model.</p>

<h2 id="public-model-contract">Public model contract</h2>

<p>A named developer model becomes part of the public catalog only when WEDNESDAY publishes all of the following:</p>

<ul>
  <li>a stable WEDNESDAY model identifier;</li>
  <li>supported input and output modalities;</li>
  <li>tool compatibility;</li>
  <li>public limits developers may rely on;</li>
  <li>lifecycle state;</li>
  <li>migration guidance when behavior is replaced or retired.</li>
</ul>

<h2 id="model-selection">Model selection</h2>

<p>Use the product-level intelligence and latency controls documented by the interface that exposes them. For routine work, start with Balanced. Use Deep Reasoning when task difficulty justifies additional reasoning. Code-oriented work can resolve to the Coding profile through runtime routing.</p>

<h2 id="lifecycle">Lifecycle</h2>

<p>Public model contracts follow an explicit lifecycle. Deprecation is announced through <a href="/deprecations/">Deprecations</a> and the <a href="/changelog/">Changelog</a> before a supported identifier is removed or materially changed.</p>


---

# Machine-readable documentation
Source: https://docs.wednesdaychat.com/machine-readable/

<h1 id="machine-readable-documentation">Machine-readable documentation</h1>

<p class="lead">WEDNESDAY publishes stable text entry points so AI agents and automated systems can discover the same public documentation humans use.</p>

<h2 id="llmstxt"><code class="language-plaintext highlighter-rouge">llms.txt</code></h2>

<p><a href="/llms.txt"><code class="language-plaintext highlighter-rouge">/llms.txt</code></a> is the compact routing index. Agents should start there when they need to discover relevant documentation without downloading the full site.</p>

<h2 id="llms-fulltxt"><code class="language-plaintext highlighter-rouge">llms-full.txt</code></h2>

<p><a href="/llms-full.txt"><code class="language-plaintext highlighter-rouge">/llms-full.txt</code></a> is a consolidated text corpus of the public documentation currently published in this repository. It is useful when a retriever needs a single ingestible source.</p>

<h2 id="search-and-crawling">Search and crawling</h2>

<p><a href="/robots.txt"><code class="language-plaintext highlighter-rouge">/robots.txt</code></a> permits public crawling and points to <a href="/sitemap.xml"><code class="language-plaintext highlighter-rouge">/sitemap.xml</code></a>. These files are publication aids; they do not grant access to non-public WEDNESDAY systems or information.</p>

<h2 id="source-integrity">Source integrity</h2>

<p>Machine consumers should treat URLs on <code class="language-plaintext highlighter-rouge">docs.wednesdaychat.com</code> as the canonical public source and preserve page titles, update dates, and lifecycle notices when indexing content.</p>


---

# Developer quickstart
Source: https://docs.wednesdaychat.com/getting-started/

<h1 id="developer-quickstart">Developer quickstart</h1>

<p class="lead">Start with the production contract that exists today: a public HTTPS origin, narrow unauthenticated operations, and session-protected product APIs.</p>

<h2 id="production-origin">Production origin</h2>

<p>The canonical WEDNESDAY API origin is:</p>

<div class="language-text highlighter-rouge"><div class="highlight"><pre class="highlight"><code>https://api.wednesdaychat.com
</code></pre></div></div>

<p>The documentation origin is independent:</p>

<div class="language-text highlighter-rouge"><div class="highlight"><pre class="highlight"><code>https://docs.wednesdaychat.com
</code></pre></div></div>

<h2 id="verify-service-health">Verify service health</h2>

<p><code class="language-plaintext highlighter-rouge">GET /health</code> is part of the deliberately public service surface.</p>

<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code>curl <span class="nt">--fail</span> <span class="nt">--silent</span> https://api.wednesdaychat.com/health
</code></pre></div></div>

<p>A healthy API returns:</p>

<div class="language-json highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="p">{</span><span class="nl">"status"</span><span class="p">:</span><span class="s2">"ok"</span><span class="p">}</span><span class="w">
</span></code></pre></div></div>

<p><code class="language-plaintext highlighter-rouge">GET /ready</code> reports whether required production dependencies are ready. It can return an HTTP <code class="language-plaintext highlighter-rouge">503</code> with a <code class="language-plaintext highlighter-rouge">not_ready</code> state when the service cannot safely accept production work.</p>

<h2 id="understand-authentication-before-calling-product-apis">Understand authentication before calling product APIs</h2>

<p>WEDNESDAY’s current production product APIs use a server-authoritative account session. Browser requests include the session credential automatically, and unsafe mutations require the WEDNESDAY CSRF header.</p>

<p>Do <strong>not</strong> construct authority by sending owner IDs, roles, plans, or retired client identity headers. The server session is authoritative.</p>

<div class="notice"><strong>External developer access:</strong> this documentation does not claim a generally available API-key authentication scheme. When WEDNESDAY publishes one, the Authentication and API Reference pages will define it as an explicit public contract.</div>

<h2 id="choose-the-right-guide">Choose the right guide</h2>

<ul>
  <li>Use <a href="/platform/conversation-state/">Conversation state</a> for durable chat state.</li>
  <li>Use <a href="/platform/streaming/">Streaming</a> for the structured SSE protocol.</li>
  <li>Use <a href="/projects/">Projects</a> for scoped context and project-owned resources.</li>
  <li>Use <a href="/files/">Files</a> for the secure upload lifecycle.</li>
  <li>Use <a href="/api/reference/">API reference</a> for verified routes and access classification.</li>
</ul>

<h2 id="machine-readable-version">Machine-readable version</h2>

<p>The raw Markdown twin for this page is available at <a href="/getting-started.md"><code class="language-plaintext highlighter-rouge">/getting-started.md</code></a>.</p>


---

# Security
Source: https://docs.wednesdaychat.com/security/

<h1 id="security">Security</h1>

<p class="lead">Public security documentation should help users integrate safely without exposing implementation details that would increase operational risk.</p>

<h2 id="documentation-security-boundary">Documentation security boundary</h2>

<p>The public repository must not contain credentials, secrets, private keys, internal-only endpoints, private network topology, customer data, confidential incident artifacts, or deployment environment files.</p>

<h2 id="responsible-publication">Responsible publication</h2>

<p>Security claims should be specific, verifiable, scoped to the applicable product surface, and reviewed before publication. Absence of a claim in this documentation should not be interpreted as a guarantee.</p>

<h2 id="vulnerability-reporting">Vulnerability reporting</h2>

<p>A dedicated public vulnerability-reporting policy will be linked here when its operational intake process is finalized.</p>


---

# Production best practices
Source: https://docs.wednesdaychat.com/production/

<h1 id="production-best-practices">Production best practices</h1>

<p class="lead">Move from prototype assumptions to production-safe WEDNESDAY integrations with explicit contracts, bounded retries, durable state reconciliation, security boundaries, and release-aware dependency management.</p>

<h2 id="treat-documented-contracts-as-the-boundary">Treat documented contracts as the boundary</h2>

<p>Depend only on behavior published in this documentation or another explicitly versioned WEDNESDAY contract. Do not build against private provider names, internal deployment topology, hidden headers, implementation-only routes, or source-code details that are not documented as supported.</p>

<h2 id="design-for-durable-state">Design for durable state</h2>

<p>WEDNESDAY is stateful. Conversations, projects, files, research tasks, feedback, sharing, and other workflows can persist independently of a single browser request. After ambiguous network failures, reconcile server state before repeating state-changing operations.</p>

<h2 id="handle-streaming-as-a-protocol">Handle streaming as a protocol</h2>

<p>Chat is delivered as a structured streaming workflow rather than a single response body. Clients should handle connection loss, terminal events, tool lifecycle state, steering acceptance, cancellation, and durable recovery without deriving state from visible text alone.</p>

<h2 id="use-bounded-retries">Use bounded retries</h2>

<ul>
  <li>honor <code class="language-plaintext highlighter-rouge">Retry-After</code> on <code class="language-plaintext highlighter-rouge">429</code>;</li>
  <li>back off on transient <code class="language-plaintext highlighter-rouge">503</code> failures;</li>
  <li>do not retry semantic <code class="language-plaintext highlighter-rouge">4xx</code> failures without changing the request;</li>
  <li>keep retries bounded and jittered;</li>
  <li>reconcile durable state after uncertain writes.</li>
</ul>

<h2 id="secure-account-owned-data">Secure account-owned data</h2>

<p>Protected WEDNESDAY operations are scoped through server-authorized account sessions. Never substitute caller-provided ownership for server-derived authority. Keep credentials, private connector tokens, session material, and internal deployment values out of client logs and public documentation.</p>

<h2 id="files-and-external-data">Files and external data</h2>

<p>Treat uploads and connector data as untrusted input. Respect file-size and media-type constraints, malware/content validation, owner scope, connector scope, and explicit approval boundaries for external actions.</p>

<h2 id="observe-dependency-health">Observe dependency health</h2>

<p>The API exposes separate health, readiness, and version behavior. A process can be alive while the platform is not ready to serve production traffic. Production systems should distinguish availability from readiness and avoid routing critical work to an unready dependency.</p>

<h2 id="release-discipline">Release discipline</h2>

<p>Production documentation changes should pass source validation, a deterministic Jekyll build, generated-site link validation, machine-readable corpus checks, and review before promotion to <code class="language-plaintext highlighter-rouge">main</code>.</p>

<div class="notice"><strong>Public docs are production surface.</strong> A documentation regression can break integrations just as surely as an API regression. WEDNESDAY treats docs, machine-readable indexes, and published API contracts as release artifacts.</div>


---

# WEDNESDAY Developer Platform
Source: https://docs.wednesdaychat.com/

<h1 id="api-platform">API Platform</h1>

<div class="quickstart-panel">
  <div class="quickstart-copy">
    <h2>Developer quickstart</h2>
    <p>Start with the production boundary, learn the session model, then build against contracts that WEDNESDAY explicitly supports.</p>
    <div class="hero-actions"><a class="button" href="/getting-started/">Get started</a><a class="button secondary" href="/api/reference/">API reference</a></div>
  </div>
  <div class="quickstart-code">
    <div class="code-label">HTTP · verify production availability</div>

```bash
curl -sS https://api.wednesdaychat.com/health
# {"status":"ok"}
```
  </div>
</div>

<div class="notice"><strong>Production boundary:</strong> most product operations are authorized through a WEDNESDAY server account session. The public API origin is documented; a general third-party API-key program is not implied until WEDNESDAY explicitly releases one.</div>

<h2 id="build-paths">Build paths</h2>

<div class="build-paths">
  <div class="build-path"><strong>Platform and API</strong><p>Understand durable state, streaming, projects, files, search, errors, rate limits, and the verified HTTP surface.</p><a href="/getting-started/">Start with the platform ↗</a></div>
  <div class="build-path"><strong>Agents and tools</strong><p>Build around typed tool execution, project context, research, connectors, approvals, and observable runtime state.</p><a href="/agents/">Explore agents ↗</a></div>
</div>

<h2 id="models">Models</h2>

<p>WEDNESDAY routes work through stable execution profiles while retaining freedom to improve the upstream provider route behind those profiles.</p>

<div class="model-catalog">
  <article class="model-card model-balanced"><a href="/models/" class="model-visual"><span>Balanced</span></a><div class="model-meta"><strong>Balanced</strong><span class="model-badge">Production</span></div><p>Responsive general-purpose work with balanced reasoning and latency.</p></article>
  <article class="model-card model-deep"><a href="/models/" class="model-visual"><span>Deep</span></a><div class="model-meta"><strong>Deep reasoning</strong><span class="model-badge">Production</span></div><p>Higher-reasoning execution for complex analysis and difficult multi-step work.</p></article>
  <article class="model-card model-code"><a href="/models/" class="model-visual"><span>Code</span></a><div class="model-meta"><strong>Coding</strong><span class="model-badge">Production</span></div><p>Code-oriented routing for software-development-heavy tasks.</p></article>
</div>

<h2 id="start-building">Start building</h2>

<div class="capability-grid">
  <a class="capability-row" href="/platform/conversation-state/"><span class="capability-icon">◯</span><span><strong>Durable conversation state</strong><small>Persist and recover conversations rather than treating every request as isolated.</small></span></a>
  <a class="capability-row" href="/platform/streaming/"><span class="capability-icon">⌁</span><span><strong>Structured streaming</strong><small>Render typed model and tool events while work is still in progress.</small></span></a>
  <a class="capability-row" href="/tools/"><span class="capability-icon">✦</span><span><strong>Tool-using applications</strong><small>Extend model execution with bounded tools, search, files, research, and connectors.</small></span></a>
  <a class="capability-row" href="/projects/"><span class="capability-icon">◇</span><span><strong>Project context</strong><small>Scope instructions, files, connectors, conversations, and work history to a project.</small></span></a>
  <a class="capability-row" href="/files/"><span class="capability-icon">▣</span><span><strong>Files and Library</strong><small>Upload, inspect, attach, retrieve, and manage account-owned files.</small></span></a>
  <a class="capability-row" href="/deep-research/"><span class="capability-icon">◎</span><span><strong>Long-running research</strong><small>Track research as durable task state rather than one fragile request.</small></span></a>
</div>

<h2 id="production-resources">Production resources</h2>

<div class="grid">
<a class="card" href="/production/"><div class="card-title">Production best practices</div><div class="card-copy">Retries, durable reconciliation, readiness, security boundaries, and release discipline.</div></a>
<a class="card" href="/security/"><div class="card-title">Security</div><div class="card-copy">Authority, account scope, connector boundaries, and safe public-contract rules.</div></a>
<a class="card" href="/machine-readable/"><div class="card-title">Machine-readable docs</div><div class="card-copy"><code>llms.txt</code>, consolidated docs, Markdown twins, search index, sitemap, and crawler guidance.</div></a>
<a class="card" href="https://status.wednesdaychat.com"><div class="card-title">Status</div><div class="card-copy">Check WEDNESDAY service health and incident communication independently of this documentation site.</div></a>
</div>

<h2 id="one-source-of-truth">One source of truth</h2>

<p>Public documentation is a production compatibility surface. Technical claims are published only when traceable to production behavior, a verified production specification, or another explicitly versioned public contract. Internal topology, secrets, provider routing, roadmap-only functionality, and privileged operational procedures stay out of the public corpus.</p>


---

# Security policy
Source: https://docs.wednesdaychat.com/SECURITY/

# Security policy

This repository contains public documentation only. Do not commit secrets, credentials, private infrastructure details, unpublished security controls, incident procedures, or internal-only API surfaces.

## Reporting a security issue

Do not open a public GitHub issue for a suspected vulnerability in WEDNESDAY. Use the private security-reporting channel published by Glass Anvil Studios or WEDNESDAY when available.

## Documentation security boundary

The documentation may describe public security guarantees and developer requirements. It must not disclose secret values, privileged operational procedures, internal network topology, private service addresses, or controls whose disclosure would materially weaken the platform.


---

# Agents
Source: https://docs.wednesdaychat.com/agents/

# Agents

<p class="lead">WEDNESDAY agent behavior is built from stateful turns, typed tool activity, durable task state, and explicit user control rather than a hidden autonomous loop.</p>

## Stateful execution

A turn belongs to authenticated durable conversation state. Project context can be loaded for the conversation before execution and rendered into the system context supplied to the turn.

## Observable activity

The stream protocol has distinct activity and tool event families. Tool execution can report start, progress, state transitions, and completion rather than collapsing all tool work into opaque text.

## Steering and cancellation

Supported turns can accept mid-turn steering while the acceptance window remains open. Durable research tasks have an explicit cancellation route.

## Approval-aware behavior

The execution protocol models approval risk and reversibility as explicit concepts. Public documentation will describe concrete approval flows only when the corresponding user/developer contract is stable.

## Agent boundary

An agent may use tools and durable state, but authorization remains server-owned. Agent execution does not bypass the account session, project ownership, file ownership, connector scope, or external-write approval boundaries.


---

# API
Source: https://docs.wednesdaychat.com/api/

# API

<p class="lead">WEDNESDAY exposes a production HTTP service at <code>https://api.wednesdaychat.com</code>. This documentation publishes the supported external contract without treating every internal service route as public API.</p>

## Production origin

```text
https://api.wednesdaychat.com
```

The web product and supported WEDNESDAY clients use this origin for durable product operations. The API is designed around account-authorized state, streaming execution, projects, files, search, research, sharing, and related platform workflows.

## Access model

Most product operations require a valid WEDNESDAY account session and derive durable ownership from server-authorized account state. Do not fabricate owner identifiers or infer a general third-party API-key program from browser/client transport details.

Start with [Authentication](/api/authentication/) before integrating a protected route.

## Reference

Use the [API reference](/api/reference/) for the deliberately published HTTP surface. The reference currently includes verified system, search, project, conversation, chat, file, and artifact capability boundaries while withholding privileged, provider-callback, administrative, and implementation-only routes.

## Errors and protection

- [Errors](/api/errors/) documents stable HTTP failure classes and retry guidance.
- [Rate limits](/api/rate-limits/) documents `429`, `Retry-After`, fail-closed protection, and quota publication policy.
- [Production best practices](/production/) covers durable-state reconciliation, streaming, readiness, security, and release discipline.

## Contract policy

Public documentation is a compatibility promise. An endpoint, header, provider model, internal module, or telemetry label found in source code is **not** automatically public API. WEDNESDAY publishes only the behavior it intends developers to depend on.

<div class="notice"><strong>Machine-readable docs:</strong> use <a href="/llms.txt"><code>/llms.txt</code></a> for routing, <a href="/llms-full.txt"><code>/llms-full.txt</code></a> for the consolidated corpus, and Markdown twins linked from individual reference pages.</div>


---

# Authentication
Source: https://docs.wednesdaychat.com/api/authentication/

# Authentication

<p class="lead">WEDNESDAY production requests are authorized through the account session boundary used by the WEDNESDAY product. Durable ownership is derived server-side from that authorized session.</p>

## Account authority

For protected operations, the API resolves the account owner from the authorized server session rather than trusting a caller-supplied owner identifier. This keeps projects, conversations, files, search results, and durable chat state scoped to the authenticated account.

## Browser requests

The production web application communicates with <code>https://api.wednesdaychat.com</code> using the WEDNESDAY session boundary. Cross-origin access is restricted to approved WEDNESDAY origins and explicitly allowed methods and headers.

## Request headers

Some production flows use WEDNESDAY-specific headers for session continuity, CSRF protection, client identity, idempotency, or turn coordination. A header appearing in the service implementation does not by itself make it a public third-party authentication mechanism.

## Third-party developer access

<div class="notice"><strong>No implied API-key program.</strong> WEDNESDAY does not document a general public API-key authentication contract until that contract is explicitly released. Do not attempt to synthesize account/session headers or rely on internal browser-session behavior from an external integration.</div>

## Authorization failures

Callers should treat authorization and session failures as terminal for the current credential context and re-establish a valid WEDNESDAY session through the supported product flow rather than retrying with fabricated identity data.


---

# Errors
Source: https://docs.wednesdaychat.com/api/errors/

# Errors

<p class="lead">WEDNESDAY uses standard HTTP status codes plus concise error detail strings. Clients should branch on status and documented semantics rather than parsing incidental implementation text.</p>

## Common status codes

| Status | Meaning |
| --- | --- |
| `400` | Invalid request shape or transport constraint. |
| `404` | Requested account-owned resource or share target was not found. |
| `409` | The requested state transition conflicts with current durable state. |
| `410` | A time-bounded resource, such as an upload session, has expired. |
| `413` | A request body exceeds the accepted size. |
| `415` | An uploaded media type or content representation is unsupported. |
| `422` | A validated parameter or identifier is semantically invalid. |
| `429` | A rate limit was exceeded. Respect `Retry-After` when supplied. |
| `503` | A required WEDNESDAY dependency or protection layer is unavailable. |

## Retry behavior

Retry only when the failure class is plausibly transient. `429` responses may include a `Retry-After` header and should not be retried before that delay. `503` can indicate unavailable persistence, cache, model access, storage, protection, or other required platform dependencies.

Do not automatically retry `400`, `404`, `409`, `410`, `413`, `415`, or `422` without changing the request or reconciling state.

## Durable conflicts

A `409` response is meaningful platform state, not a generic transport failure. Examples include trying to mutate a resource after its state has moved on or submitting steering after a turn is no longer accepting input.

## Error text

<div class="notice">Error detail strings are intended for diagnostics, but clients should not treat undocumented wording as a stable machine contract. Stable client behavior should key off HTTP status and fields explicitly documented for the endpoint.</div>


---

# Rate limits
Source: https://docs.wednesdaychat.com/api/rate-limits/

# Rate limits

<p class="lead">WEDNESDAY applies protection at the production service boundary. Chat and durable-state operations use dedicated rate-limit paths, and the platform can fail closed when protection infrastructure is unavailable.</p>

## What is limited

Verified production code applies rate-limit enforcement to chat traffic and to conversation-oriented persistence flows used by search, projects, files, feedback, sharing, and related durable operations.

## `429 Too Many Requests`

When a limit is exceeded, the API returns `429`. Where available, the response includes `Retry-After` with the number of seconds a client should wait before retrying.

```http
HTTP/1.1 429 Too Many Requests
Retry-After: 12
Content-Type: application/json
```

## Protection availability

WEDNESDAY does not silently bypass protection when its rate-limit layer cannot make a trustworthy decision. A protection dependency failure can surface as `503 Service Unavailable` instead of allowing unprotected traffic.

## Published quotas

<div class="notice"><strong>No invented quotas.</strong> Numeric request-per-minute or token quotas are not published until they are a stable product contract. Clients should implement backoff for `429` independently of any assumed quota.</div>

## Client guidance

Use bounded exponential backoff, honor `Retry-After`, avoid retry storms, and keep idempotent operations safe to replay where the endpoint contract allows it. For state-changing requests, reconcile the durable result before blindly retrying after network uncertainty.


---

# API reference
Source: https://docs.wednesdaychat.com/api/reference/

# API reference

<p class="lead">The production API origin is <code>https://api.wednesdaychat.com</code>. This reference documents only routes and behaviors that are verified in the production service and safe to publish.</p>

<div class="notice"><strong>Access boundary:</strong> WEDNESDAY currently uses server-authorized account sessions for most product operations. The existence of an HTTP route does not imply an unrestricted third-party API-key contract.</div>

## System

<div class="endpoint"><div class="endpoint-head"><span class="method">GET</span><span class="endpoint-path">/health</span></div><div class="endpoint-body"><p>Lightweight service health probe. Returns an <code>ok</code> health status when the API process is available.</p></div></div>

<div class="endpoint"><div class="endpoint-head"><span class="method">GET</span><span class="endpoint-path">/ready</span></div><div class="endpoint-body"><p>Production readiness probe. Readiness depends on required backing services including persistence, cache, object storage, malware scanning, and model access.</p></div></div>

<div class="endpoint"><div class="endpoint-head"><span class="method">GET</span><span class="endpoint-path">/version</span></div><div class="endpoint-body"><p>Returns the WEDNESDAY API service identity, environment, build SHA when available, and configured model-provider family. The response is marked <code>no-store</code>.</p></div></div>

## Search

<div class="endpoint"><div class="endpoint-head"><span class="method">GET</span><span class="endpoint-path">/search?q=…</span></div><div class="endpoint-body"><p>Searches durable account-owned WEDNESDAY state. Query text is required and bounded; result size is bounded by the service.</p></div></div>

## Projects

Verified project operations include listing, creating, loading, renaming, archiving, restoring, and deleting projects; reading and updating project settings and instructions; project search; project conversations; file membership; connector bindings; and work history.

## Conversations

Verified conversation operations include listing and loading conversations, messages, drafts, follow-ups, branches, archive state, pin state, project movement, feedback, sharing, usage recording, and durable deletion.

## Chat streaming

<div class="endpoint"><div class="endpoint-head"><span class="method post">POST</span><span class="endpoint-path">/chat</span></div><div class="endpoint-body"><p>Starts a durable streaming chat turn for the authorized account. The stream is explicitly non-cacheable and supports structured runtime events.</p></div></div>

<div class="endpoint"><div class="endpoint-head"><span class="method post">POST</span><span class="endpoint-path">/chat/{turn_id}/input</span></div><div class="endpoint-body"><p>Submits mid-turn steering input to an active turn. Durable cancellation is supported when the turn identifier resolves to a durable chat turn.</p></div></div>

## Files and artifacts

The production service exposes owner-scoped file upload, file inspection, file-library, picker, attachment-state, download, message-attachment, assistant-artifact, location-context, memory-source-consent, and deep-research routers. Individual contracts are published only after their request/response schemas are stable enough to support externally.

## Contract policy

Routes used only for internal operations, provider callbacks, privileged administration, deployment, or implementation-specific coordination are intentionally omitted. Public documentation is a compatibility promise; source-code presence alone is not.


---

# Changelog
Source: https://docs.wednesdaychat.com/changelog/

# Changelog

## September 14, 2026

### Documentation infrastructure

- Established `docs.wednesdaychat.com` on GitHub Pages.
- Configured the custom domain and enforced HTTPS.
- Established `main` as the production documentation branch.
- Added the initial public documentation architecture and machine-readable discovery files.

Platform feature changes will be listed here only when verified against the relevant production contract.


---

# Deep research
Source: https://docs.wednesdaychat.com/deep-research/

# Deep research

<p class="lead">Deep research work is represented by durable, account-owned task records so longer-running research can be inspected independently of a single browser stream.</p>

## Task routes

| Method | Route | Purpose |
| --- | --- | --- |
| `GET` | `/conversations/{conversation_id}/research-tasks` | List research tasks for a conversation |
| `GET` | `/research-tasks/{task_id}` | Load one task |
| `POST` | `/research-tasks/{task_id}/cancel` | Request cancellation |

Conversation task listing accepts a bounded `limit` from 1 to 100 with a default of 20.

## Durable ownership

Research tasks are resolved inside the authenticated account boundary. Task and conversation identifiers do not replace session authority.

## Lifecycle errors

- `404` — the task or associated resource is not available to the account.
- `409` — the requested lifecycle transition conflicts with current task state.
- `422` — a supplied value violates the public request contract.
- `429` — the research-work protection limit is exceeded.
- `503` — task persistence or protection is unavailable.

## Cache behavior

Task reads and cancellation responses are emitted with `Cache-Control: no-store` so clients do not reuse stale research state.


---

# Deprecations
Source: https://docs.wednesdaychat.com/deprecations/

# Deprecations

<p class="lead">This page is the canonical public index for WEDNESDAY deprecation notices that affect documented contracts.</p>

## Current notices

There are no public deprecation notices recorded in this documentation repository at this time.

When a deprecation is published, the notice should identify the affected contract, announcement date, replacement path, migration guidance, and retirement date when one has been committed.


---

# Public Content Boundary
Source: https://docs.wednesdaychat.com/docs/CONTENT_BOUNDARY/

# Public Content Boundary

The public documentation repository contains only information intended for external consumption.

## Publish

- stable developer-facing platform behavior;
- supported workflows and capability families;
- public API origins and explicitly supported routes;
- public authentication, error, rate-limit, lifecycle, security, privacy, and reliability behavior;
- public model profiles and stable model IDs only when formally released;
- changelog and deprecation guidance;
- machine-readable documentation mirrors.

## Do not publish

- credentials, secrets, private keys, tokens, or protected session material;
- private network topology, internal addresses, or privileged deployment instructions;
- operational runbooks whose disclosure would weaken production security;
- unreleased roadmap items presented as shipping capability;
- internal provider routing presented as a permanent WEDNESDAY model contract;
- private administrator or provider-callback surfaces unless explicitly intended as a public integration contract.

When uncertain, omit the claim until its public support boundary is verified.


---

# WEDNESDAY Documentation Release Standard
Source: https://docs.wednesdaychat.com/docs/RELEASE_STANDARD/

# WEDNESDAY Documentation Release Standard

`docs.wednesdaychat.com` is a production surface. Documentation changes are released with the same evidence-oriented discipline used for WEDNESDAY operational systems.

## Required gates

1. Public technical claims are traceable to production behavior, a production specification, or another explicitly versioned public contract.
2. Public docs do not disclose secrets, privileged operational procedures, private infrastructure topology, or roadmap-only functionality.
3. Human pages and required Markdown twins remain synchronized.
4. `llms.txt`, `llms-full.txt`, search, crawler, and sitemap surfaces remain valid.
5. CI builds the production Jekyll output and validates generated internal links and metadata.
6. Compatibility-affecting changes are reflected in the changelog or deprecation record.
7. Production is promoted from a reviewed commit only after required checks pass.

## Source precedence

For developer-facing behavior, precedence is:

1. explicitly versioned public contract;
2. verified current production behavior;
3. production deployment specification;
4. internal design/roadmap material for context only.

Roadmaps and private implementation details are never sufficient by themselves to create a public compatibility promise.


---

# WEDNESDAY Developer Documentation UI Principles
Source: https://docs.wednesdaychat.com/docs/UI_REFERENCE/

# WEDNESDAY Developer Documentation UI Principles

The WEDNESDAY developer experience uses leading frontier developer-documentation patterns as inspiration while maintaining distinct WEDNESDAY branding and information architecture.

## Interaction principles

- dark-first, high-contrast developer UI with optional light mode;
- compact global navigation plus a second platform navigation row;
- persistent grouped left documentation taxonomy;
- focused technical reading column and contextual right-side page outline;
- command search available from keyboard and header;
- code copy and page copy actions;
- responsive navigation for mobile and smaller screens;
- model, tool, learning, and production surfaces designed as first-class catalogs rather than flat prose;
- public operational status linked independently from the docs host.

## Content principles

- publish production contracts, not implementation trivia;
- show code and workflow examples next to conceptual guidance;
- separate platform concepts from endpoint reference;
- expose machine-readable equivalents for model and agent retrieval;
- keep model/provider routing abstractions separate from stable public model IDs;
- treat docs regressions as production regressions.


---

# Files
Source: https://docs.wednesdaychat.com/files/

# Files

<p class="lead">File intake uses an explicit upload-session lifecycle so WEDNESDAY can validate ownership, metadata, transport, content, and storage state before a file becomes usable.</p>

## Upload lifecycle

The production upload flow exposes three core operations:

| Method | Route | Purpose |
| --- | --- | --- |
| `POST` | `/files/uploads` | Initiate an owner-scoped upload session |
| `GET` | `/files/uploads/{upload_id}` | Read upload progress and state |
| `PUT` | `/files/uploads/{upload_id}/content` | Stream the complete file body |

Upload initiation uses an `Idempotency-Key` header so safe retries can refer to the same initiation intent.

## Transport rules

The content upload is intentionally strict:

- compressed request bodies are not accepted;
- partial `Content-Range` resume is not supported;
- a retry sends the upload body again from byte zero;
- the body media type must match the initiated session or use `application/octet-stream`;
- declared and observed size are validated against the session.

## Validation and failure states

The file pipeline distinguishes malformed requests, unsupported media, invalid content, oversized files, expired sessions, missing sources, conflicts, rate limits, and temporary service failures.

Relevant HTTP outcomes include `400`, `404`, `409`, `410`, `413`, `415`, `429`, and `503`.

## Library and attachments

The production file router also supports owner-scoped Library views, file picker results, attachment-state lookup, user-message attachment preparation, and secure file inspection/download paths.

<div class="notice"><strong>Security boundary:</strong> file IDs do not grant authority. File operations are evaluated inside the authenticated account session.</div>


---

# Developer quickstart
Source: https://docs.wednesdaychat.com/getting-started/

# Developer quickstart

<p class="lead">Start with the production contract that exists today: a public HTTPS origin, narrow unauthenticated operations, and session-protected product APIs.</p>

## Production origin

The canonical WEDNESDAY API origin is:

```text
https://api.wednesdaychat.com
```

The documentation origin is independent:

```text
https://docs.wednesdaychat.com
```

## Verify service health

`GET /health` is part of the deliberately public service surface.

```bash
curl --fail --silent https://api.wednesdaychat.com/health
```

A healthy API returns:

```json
{"status":"ok"}
```

`GET /ready` reports whether required production dependencies are ready. It can return an HTTP `503` with a `not_ready` state when the service cannot safely accept production work.

## Understand authentication before calling product APIs

WEDNESDAY's current production product APIs use a server-authoritative account session. Browser requests include the session credential automatically, and unsafe mutations require the WEDNESDAY CSRF header.

Do **not** construct authority by sending owner IDs, roles, plans, or retired client identity headers. The server session is authoritative.

<div class="notice"><strong>External developer access:</strong> this documentation does not claim a generally available API-key authentication scheme. When WEDNESDAY publishes one, the Authentication and API Reference pages will define it as an explicit public contract.</div>

## Choose the right guide

- Use [Conversation state](/platform/conversation-state/) for durable chat state.
- Use [Streaming](/platform/streaming/) for the structured SSE protocol.
- Use [Projects](/projects/) for scoped context and project-owned resources.
- Use [Files](/files/) for the secure upload lifecycle.
- Use [API reference](/api/reference/) for verified routes and access classification.

## Machine-readable version

The raw Markdown twin for this page is available at [`/getting-started.md`](/getting-started/).


---

# Integrations
Source: https://docs.wednesdaychat.com/integrations/

# Integrations

<p class="lead">Integrations connect WEDNESDAY to external systems without collapsing external authorization into the model or the browser client.</p>

## Project connector bindings

Projects expose an owner-scoped connector-binding view and an explicit unbind operation. A connector binding belongs to the authenticated project/account context; possession of a binding ID alone is not authorization.

## GitHub

The production codebase includes GitHub authorization, repository, reference-context, workspace, branch, and patch workflows. GitHub callback/webhook operations are operational integration surfaces and are not interchangeable with user-facing project APIs.

## Separation of concerns

A production integration has multiple independent boundaries:

1. the WEDNESDAY account session;
2. the external provider authorization or installation;
3. resource-level scope inside that provider;
4. approval requirements for writes or destructive actions.

## Public integration contract

This documentation publishes integration behavior that users and developers may rely on. It intentionally omits secret handling, private webhook validation details, installation credentials, internal provider tokens, and privileged operational procedures.

## Revocation

Where the product exposes an unbind or disconnect operation, clients should treat revocation as a first-class lifecycle state rather than assuming access remains valid indefinitely.


---

# Machine-readable documentation
Source: https://docs.wednesdaychat.com/machine-readable/

# Machine-readable documentation

<p class="lead">WEDNESDAY publishes stable text entry points so AI agents and automated systems can discover the same public documentation humans use.</p>

## `llms.txt`

[`/llms.txt`](/llms.txt) is the compact routing index. Agents should start there when they need to discover relevant documentation without downloading the full site.

## `llms-full.txt`

[`/llms-full.txt`](/llms-full.txt) is a consolidated text corpus of the public documentation currently published in this repository. It is useful when a retriever needs a single ingestible source.

## Search and crawling

[`/robots.txt`](/robots.txt) permits public crawling and points to [`/sitemap.xml`](/sitemap.xml). These files are publication aids; they do not grant access to non-public WEDNESDAY systems or information.

## Source integrity

Machine consumers should treat URLs on `docs.wednesdaychat.com` as the canonical public source and preserve page titles, update dates, and lifecycle notices when indexing content.


---

# Models
Source: https://docs.wednesdaychat.com/models/

# Models

<p class="lead">Choose the execution profile that matches the work. WEDNESDAY owns the routing contract while retaining freedom to improve the underlying provider route as long as the published profile behavior remains compatible.</p>

## Choose an execution profile

<div class="model-catalog">
  <article class="model-card model-balanced">
    <div class="model-visual"><span>Balanced</span></div>
    <div class="model-meta"><strong>Balanced</strong><span class="model-badge">Production</span></div>
    <p>Default conversational profile for responsive, general-purpose work with balanced reasoning and latency.</p>
  </article>
  <article class="model-card model-deep">
    <div class="model-visual"><span>Deep</span></div>
    <div class="model-meta"><strong>Deep reasoning</strong><span class="model-badge">Production</span></div>
    <p>Higher-reasoning profile for complex analysis and tasks where depth matters more than minimum latency.</p>
  </article>
  <article class="model-card model-code">
    <div class="model-visual"><span>Code</span></div>
    <div class="model-meta"><strong>Coding</strong><span class="model-badge">Production</span></div>
    <p>Code-oriented execution route used when the runtime classifies the work as software-development heavy.</p>
  </article>
</div>

<div class="notice"><strong>Profile ≠ provider model ID.</strong> WEDNESDAY can change an upstream route without renaming a WEDNESDAY execution profile when the public behavior remains compatible. Upstream provider identifiers are not a permanent developer contract unless explicitly published as one.</div>

## Routing is observable

The streaming protocol can represent resolved routing information for a turn, including a model identifier, model role, requested and resolved intelligence level, latency profile, reasoning profile, and bounded completion behavior. Those fields make execution observable; they do not automatically turn every internal route target into a permanently supported developer model.

## Public model contract

A named developer model becomes part of the public catalog only when WEDNESDAY publishes all of the following:

- a stable WEDNESDAY model identifier;
- supported input and output modalities;
- tool compatibility;
- public limits developers may rely on;
- lifecycle state;
- migration guidance when behavior is replaced or retired.

## Model selection

Use the product-level intelligence and latency controls documented by the interface that exposes them. For routine work, start with Balanced. Use Deep Reasoning when task difficulty justifies additional reasoning. Code-oriented work can resolve to the Coding profile through runtime routing.

## Lifecycle

Public model contracts follow an explicit lifecycle. Deprecation is announced through [Deprecations](/deprecations/) and the [Changelog](/changelog/) before a supported identifier is removed or materially changed.


---

# Key concepts
Source: https://docs.wednesdaychat.com/platform/

# Key concepts

<p class="lead">WEDNESDAY combines server-owned identity, durable conversation state, structured streaming, project context, and tool-oriented execution into one product runtime.</p>

## Server-authoritative identity

Protected operations derive the durable account owner from the validated server session. Client-supplied owner or role claims are not the authority boundary.

This design keeps conversation, project, file, search, feedback, and tool state consistently scoped to the authenticated account.

## Durable conversations

Conversation records are persisted independently of the live model stream. The platform supports conversation listing and loading, messages, drafts, follow-ups, branches, archive state, pinning, project movement, feedback, sharing, usage records, and deletion.

[Read about conversation state →](/platform/conversation-state/)

## Structured streaming

Live chat responses use Server-Sent Events (`text/event-stream`) with a versioned event protocol. Events carry ordered sequence numbers and typed state for turns, answers, code, activities, and tools.

[Read about streaming →](/platform/streaming/)

## Mid-turn steering

A running turn can accept supported steering input while it remains steerable. The server rejects steering after the acceptance window closes rather than silently pretending it was applied.

[Read about steering →](/platform/steering/)

## Projects and context

Projects group conversations and related context. Production routes support project settings, instructions, search, files, connector bindings, work history, and project-scoped conversations.

[Read about projects →](/projects/)

## Fail-closed API surface

The production API treats unlisted routes as session-required by default. Only an explicit narrow public allowlist is available without an account session.


---

# Conversation state
Source: https://docs.wednesdaychat.com/platform/conversation-state/

# Conversation state

<p class="lead">Conversation state is a durable server-owned resource. It is scoped to the authenticated account and remains separate from the transport of a single live model response.</p>

## Core routes

| Method | Route | Purpose |
| --- | --- | --- |
| `GET` | `/conversations` | List account-owned conversations with cursor pagination |
| `GET` | `/conversations/{conversation_id}` | Load one conversation |
| `PUT` | `/conversations/{conversation_id}` | Persist a conversation write |
| `PUT` | `/conversations/{conversation_id}/title` | Update the title |
| `GET` | `/conversations/{conversation_id}/messages` | Page through messages |
| `PUT` | `/conversations/{conversation_id}/draft` | Persist the composer draft |
| `DELETE` | `/conversations/{conversation_id}` | Delete the conversation |

All routes in this table require the validated WEDNESDAY account session.

## Follow-ups and branches

The API supports queued follow-ups, follow-up reordering and state changes, creation of conversation branches from a message, and switching the active branch.

Branch operations remain conversation-owner scoped. A client cannot select another account's durable owner by supplying an owner identifier.

## Organization state

Conversation records can be archived, pinned, and moved into or out of projects. Project-move targets are returned from an owner-scoped route so the client does not need to infer allowed destinations.

## Feedback and sharing

Feedback is stored against the latest eligible response in the conversation. Share creation is session-protected, while resolution of a valid share token is part of the intentionally public surface.

## Consistency behavior

The persistence layer distinguishes missing resources, conflicts, rate limits, and temporary store failures. Clients should handle `404`, `409`, `429`, and `503` as distinct states rather than retrying every failure identically.


---

# Mid-turn steering
Source: https://docs.wednesdaychat.com/platform/steering/

# Mid-turn steering

<p class="lead">WEDNESDAY can accept supported input during a running turn instead of forcing every correction into a brand-new conversation turn.</p>

## Endpoint

<div class="endpoint"><div class="endpoint-head"><span class="method post">POST</span><span class="endpoint-path">/chat/{turn_id}/input</span></div><div class="endpoint-body"><p>Submit a validated steering payload to an active turn. Successful submission returns HTTP <code>202</code>.</p></div></div>

The operation is account-session protected and uses the same chat-rate-limit boundary as the live chat route.

## Acceptance window

Steering is not guaranteed after a turn stops accepting input. When the transport can no longer deliver steering, the API returns `409 Conflict` rather than acknowledging input that was not applied.

## Cancellation

Supported steering payloads can represent durable turn cancellation. Cancellation validates the durable turn identifier and persists the cancel request before the turn is treated as cancelled.

## Error behavior

- `404` — the durable turn does not exist for the account.
- `409` — the turn is no longer accepting steering.
- `422` — the cancellation form contains an invalid durable turn identifier.
- `429` — the chat rate limit is exceeded.
- `503` — steering transport, cancellation persistence, or rate-limit protection is unavailable.

Clients should surface these outcomes distinctly; a `409` is a lifecycle outcome, not a generic server failure.


---

# Streaming
Source: https://docs.wednesdaychat.com/platform/streaming/

# Streaming

<p class="lead">Live chat uses Server-Sent Events with a versioned, ordered event protocol rather than an unstructured text socket.</p>

## Transport

`POST /chat` returns:

```text
Content-Type: text/event-stream
Cache-Control: no-cache, no-transform
X-Accel-Buffering: no
```

The route requires an authenticated account session and is protected by the chat rate limiter.

## Protocol version

Current stream events carry `protocol_version: 1`, a turn identifier, and a monotonically ordered sequence field. Part-level events add a part identifier; tool events add a tool identifier.

Clients should treat the protocol version as part of the compatibility contract rather than assuming event payloads can change without coordination.

## Event families

The current stream model includes typed events for:

- turn start and routing;
- activity progress;
- answer start, delta, and completion;
- code start, delta, and completion;
- tool start, progress, state transitions, and completion;
- additional bounded platform events as documented by their public contract.

## Backpressure and intermediaries

The API disables response buffering and transformation for the stream. Clients should consume events incrementally and should not depend on intermediaries coalescing chunks.

## Durable state is separate

Streaming transports live execution. Conversation persistence is a separate durable boundary. A robust client should not assume that the presence or absence of one network chunk is itself the durable conversation record.


---

# Privacy
Source: https://docs.wednesdaychat.com/privacy/

# Privacy

<p class="lead">WEDNESDAY scopes durable product data to the authorized account and documents privacy-relevant behavior only where it is a stable public contract.</p>

## Account-scoped state

Projects, conversations, files, search results, feedback, research state, and related durable records are resolved through the authorized account boundary. Public share links are a deliberate exception: they expose only the share target represented by the generated share token.

## Data minimization

Clients should send only the information required for the requested workflow. Do not place secrets, credentials, or unrelated personal data into prompts, project instructions, file metadata, tool arguments, logs, or public share links.

## Files and connectors

Files and connector-backed resources remain subject to owner and connector scope. Applications should preserve the user's authorization boundary when displaying, caching, exporting, or acting on retrieved data.

## Public documentation

This public documentation intentionally excludes secret configuration, internal endpoints, private deployment topology, incident procedures, privileged administration behavior, and implementation details that would unnecessarily expand the public data surface.

## Product policy

<div class="notice">This developer page describes technical privacy boundaries, not the full WEDNESDAY consumer privacy policy or legal terms. Product-facing privacy notices remain authoritative for legal disclosures and user rights.</div>


---

# Production best practices
Source: https://docs.wednesdaychat.com/production/

# Production best practices

<p class="lead">Move from prototype assumptions to production-safe WEDNESDAY integrations with explicit contracts, bounded retries, durable state reconciliation, security boundaries, and release-aware dependency management.</p>

## Treat documented contracts as the boundary

Depend only on behavior published in this documentation or another explicitly versioned WEDNESDAY contract. Do not build against private provider names, internal deployment topology, hidden headers, implementation-only routes, or source-code details that are not documented as supported.

## Design for durable state

WEDNESDAY is stateful. Conversations, projects, files, research tasks, feedback, sharing, and other workflows can persist independently of a single browser request. After ambiguous network failures, reconcile server state before repeating state-changing operations.

## Handle streaming as a protocol

Chat is delivered as a structured streaming workflow rather than a single response body. Clients should handle connection loss, terminal events, tool lifecycle state, steering acceptance, cancellation, and durable recovery without deriving state from visible text alone.

## Use bounded retries

- honor `Retry-After` on `429`;
- back off on transient `503` failures;
- do not retry semantic `4xx` failures without changing the request;
- keep retries bounded and jittered;
- reconcile durable state after uncertain writes.

## Secure account-owned data

Protected WEDNESDAY operations are scoped through server-authorized account sessions. Never substitute caller-provided ownership for server-derived authority. Keep credentials, private connector tokens, session material, and internal deployment values out of client logs and public documentation.

## Files and external data

Treat uploads and connector data as untrusted input. Respect file-size and media-type constraints, malware/content validation, owner scope, connector scope, and explicit approval boundaries for external actions.

## Observe dependency health

The API exposes separate health, readiness, and version behavior. A process can be alive while the platform is not ready to serve production traffic. Production systems should distinguish availability from readiness and avoid routing critical work to an unready dependency.

## Release discipline

Production documentation changes should pass source validation, a deterministic Jekyll build, generated-site link validation, machine-readable corpus checks, and review before promotion to `main`.

<div class="notice"><strong>Public docs are production surface.</strong> A documentation regression can break integrations just as surely as an API regression. WEDNESDAY treats docs, machine-readable indexes, and published API contracts as release artifacts.</div>


---

# Projects
Source: https://docs.wednesdaychat.com/projects/

# Projects

<p class="lead">Projects group durable conversations and project-scoped context under the authenticated WEDNESDAY account.</p>

## Project lifecycle

The production API supports listing, reading, creating, renaming, archiving, deleting, and restoring projects.

| Method | Route |
| --- | --- |
| `GET` | `/projects` |
| `POST` | `/projects` |
| `GET` | `/projects/{project_id}` |
| `PUT` | `/projects/{project_id}/name` |
| `PUT` | `/projects/{project_id}/archive` |
| `DELETE` | `/projects/{project_id}` |
| `POST` | `/projects/{project_id}/restore` |

## Project context

A project can expose account-owned settings and instructions through dedicated read/write routes. Chat execution can load project context for a conversation and render that context into the turn's system context.

## Search and resources

Projects have production routes for:

- project-scoped search;
- instructions and settings;
- connector bindings;
- work history;
- file membership;
- project-owned conversation listing and creation.

## Ownership boundary

Every project operation in this guide is session-protected. The project ID selects a resource **within** the authenticated account; it does not select the account itself.

## Conflicts and deletion

Mutating operations may return `409 Conflict` when state has changed or an explicit confirmation requirement is not satisfied. Clients should not collapse those outcomes into a generic retry loop.


---

# Reliability
Source: https://docs.wednesdaychat.com/reliability/

# Reliability

<p class="lead">Reliability documentation explains externally observable behavior: availability, retries, timeouts, idempotency, degradation, and status communication where those contracts are publicly defined.</p>

## Status information

Live operational status belongs on the independent WEDNESDAY status service rather than being hard-coded into documentation pages. Documentation should explain behavior; the status service should report current incidents and availability.

## Failure semantics

API and tool references should document actionable error behavior close to the affected contract so developers do not have to infer retry or recovery behavior.


---

# Search
Source: https://docs.wednesdaychat.com/search/

# Search

<p class="lead">Search is a server-owned, account-scoped operation over durable WEDNESDAY state. It is separate from model web search.</p>

## Global search

<div class="endpoint"><div class="endpoint-head"><span class="method">GET</span><span class="endpoint-path">/search</span></div><div class="endpoint-body"><p>Search the authenticated account's durable search surface.</p></div></div>

The verified query contract uses:

| Parameter | Constraint |
| --- | --- |
| `q` | Required; 1–160 characters |
| `limit` | 1–100; default 25 |

Results are returned with `Cache-Control: no-store`.

## Project search

<div class="endpoint"><div class="endpoint-head"><span class="method">GET</span><span class="endpoint-path">/projects/{project_id}/search</span></div><div class="endpoint-body"><p>Search within an account-owned project, including a bounded filter and result limit.</p></div></div>

## Rate limits and errors

Search can return:

- `422` for an invalid query contract;
- `429` when the search protection limit is exceeded;
- `503` when search storage or protection is unavailable.

## Not the same as web search

This page documents product-state search. Model tools that discover or ground information from the public web have a separate execution and security boundary and should not be inferred from `/search`.


---

# Security
Source: https://docs.wednesdaychat.com/security/

# Security

<p class="lead">Public security documentation should help users integrate safely without exposing implementation details that would increase operational risk.</p>

## Documentation security boundary

The public repository must not contain credentials, secrets, private keys, internal-only endpoints, private network topology, customer data, confidential incident artifacts, or deployment environment files.

## Responsible publication

Security claims should be specific, verifiable, scoped to the applicable product surface, and reviewed before publication. Absence of a claim in this documentation should not be interpreted as a guarantee.

## Vulnerability reporting

A dedicated public vulnerability-reporting policy will be linked here when its operational intake process is finalized.


---

# Using tools
Source: https://docs.wednesdaychat.com/tools/

# Using tools

<p class="lead">Extend a WEDNESDAY turn with search, files, research, location context, projects, connectors, and other bounded execution capabilities. Tool work is represented as typed runtime state rather than hidden model side effects.</p>

<div class="tool-tabs" role="list" aria-label="Tool families">
<span class="tool-tab active">Search</span><span class="tool-tab">Files</span><span class="tool-tab">Research</span><span class="tool-tab">Projects</span><span class="tool-tab">Connectors</span>
</div>

```text
User request
   ↓
WEDNESDAY runtime
   ↓
Tool start → progress/state → completion
   ↓
Structured result returned to the active turn
```

## Available tool families

<div class="capability-grid">
  <a class="capability-row" href="/search/"><span class="capability-icon">⌕</span><span><strong>Search and retrieval</strong><small>Search durable WEDNESDAY state and support retrieval-oriented workflows.</small></span></a>
  <a class="capability-row" href="/files/"><span class="capability-icon">▣</span><span><strong>Files and Library</strong><small>Upload, inspect, select, attach, retrieve, and manage account-owned file resources.</small></span></a>
  <a class="capability-row" href="/deep-research/"><span class="capability-icon">✦</span><span><strong>Deep research</strong><small>Track longer-running research work as durable task state rather than a single request.</small></span></a>
  <a class="capability-row" href="/projects/"><span class="capability-icon">◇</span><span><strong>Projects and context</strong><small>Use project instructions, settings, files, conversations, connectors, and work history as scoped context.</small></span></a>
  <a class="capability-row" href="/integrations/"><span class="capability-icon">↗</span><span><strong>Connectors</strong><small>Work with explicitly authorized external resources while preserving connector scope and approval boundaries.</small></span></a>
  <a class="capability-row" href="/platform/"><span class="capability-icon">◎</span><span><strong>Location and place context</strong><small>Use location preferences and place-enrichment capabilities where the product flow authorizes them.</small></span></a>
</div>

## Tool lifecycle

The live stream protocol can represent tool start, progress, state transition, and completion events. Stable turn, part, and tool hierarchy identifiers let a client render nested or parallel work without inferring execution state from prose.

## Authority and approvals

Tool availability never implies unlimited authority. File operations remain account-scoped, connector operations remain connector-scoped, public-network access is bounded by runtime policy, and risky external actions can require explicit approval before execution.

## Failure handling

A tool result can fail independently of the surrounding model turn. Clients should preserve tool state, surface meaningful failures, and avoid rewriting a failed execution as if the model merely “changed its mind.”

## Public capability policy

A tool becomes a supported developer capability only when its public name, inputs, outputs, authority requirements, failure behavior, and lifecycle are stable enough to depend on.

<div class="notice">Internal tool kinds, telemetry labels, and implementation-specific execution modules are not automatically public developer tools.</div>