> ## Documentation Index > Fetch the complete documentation index at: https://docs.hyperspell.com/llms.txt > Use this file to discover all available pages before exploring further. # Get the latest context document tree > Get the most recent context document tree for the authenticated app. The sync daemon polls this endpoint to fetch updated files. Default behaviour: serve the latest "ready" tree, where "ready" depends on whether the app has `require_review` enabled: - `require_review=False` (default): latest COMPLETED ships immediately. - `require_review=True`: latest PUBLISHED only — apps that gate on a curator's approval before the daemon picks up the new tree. `?status=` filters to a specific status (case-insensitive). `?include_published=true` returns the absolute latest tree (any status) so the dashboard can surface an in-flight PROCESSING generation when the user navigates away mid-gen and back. The daemon path (no `include_published`) keeps strict status filtering. Auto-trigger semantics replace the pre-Temporal lazy ``BackgroundTasks`` path: * If the app has no tree at all and the caller has a user_key, a full ``TreeGenerationWorkflow`` is dispatched with ``user_id=user_key`` so its in-line Phase 4 populates this user's overrides. The endpoint still 404s on this poll; the daemon will see a PROCESSING tree on its next poll. * If the latest COMPLETED tree has no ``personal_overrides`` entry for the caller, a lightweight ``PersonalDocWorkflow`` is dispatched against that tree to backfill just this user's override block. The response is still served immediately with placeholder personal/*.md content — as a lightweight 304 when the caller already presents the current ETag (FT-184) — and the next poll after the backfill lands merges the generated content in (the override changes the ETag, so that poll gets a fresh 200). Both dispatches use deterministic workflow IDs that also dedupe with Phase 4's child-workflow dispatch from ``TreeGenerationWorkflow``, so concurrent runs never race against each other. ## OpenAPI ````yaml https://app.stainlessapi.com/api/spec/documented/hyperspell.yaml get /context-documents/tree/latest openapi: 3.1.0 info: title: Hyperspell API summary: >- Hyperspell is the memory layer for AI apps and agents. Through the API, you can add memories, connect data sources to index them in real-time, and search memories with our natural language query engine. termsOfService: https://hyperspell.com/blog/tos contact: name: Hyperspell url: https://hyperspell.com/ email: hello@hyperspell.com version: 0.32.1 servers: - url: https://api.hyperspell.com description: Production security: - APIKey: [] AsUser: [] paths: /context-documents/tree/latest: get: tags: - Context Documents summary: Get the latest context document tree description: |- Get the most recent context document tree for the authenticated app. The sync daemon polls this endpoint to fetch updated files. Default behaviour: serve the latest "ready" tree, where "ready" depends on whether the app has `require_review` enabled: - `require_review=False` (default): latest COMPLETED ships immediately. - `require_review=True`: latest PUBLISHED only — apps that gate on a curator's approval before the daemon picks up the new tree. `?status=` filters to a specific status (case-insensitive). `?include_published=true` returns the absolute latest tree (any status) so the dashboard can surface an in-flight PROCESSING generation when the user navigates away mid-gen and back. The daemon path (no `include_published`) keeps strict status filtering. Auto-trigger semantics replace the pre-Temporal lazy ``BackgroundTasks`` path: * If the app has no tree at all and the caller has a user_key, a full ``TreeGenerationWorkflow`` is dispatched with ``user_id=user_key`` so its in-line Phase 4 populates this user's overrides. The endpoint still 404s on this poll; the daemon will see a PROCESSING tree on its next poll. * If the latest COMPLETED tree has no ``personal_overrides`` entry for the caller, a lightweight ``PersonalDocWorkflow`` is dispatched against that tree to backfill just this user's override block. The response is still served immediately with placeholder personal/*.md content — as a lightweight 304 when the caller already presents the current ETag (FT-184) — and the next poll after the backfill lands merges the generated content in (the override changes the ETag, so that poll gets a fresh 200). Both dispatches use deterministic workflow IDs that also dedupe with Phase 4's child-workflow dispatch from ``TreeGenerationWorkflow``, so concurrent runs never race against each other. operationId: get_latest_tree_context_documents_tree_latest_get parameters: - name: status in: query required: false schema: anyOf: - type: string - type: 'null' title: Status - name: include_published in: query required: false schema: type: boolean default: false title: Include Published responses: '200': description: Successful Response content: application/json: schema: $ref: '#/components/schemas/TreeResponse' '422': description: Validation Error content: application/json: schema: $ref: '#/components/schemas/HTTPValidationError' security: - APIKey: [] - AsUser: [] components: schemas: TreeResponse: properties: tree_id: type: string title: Tree Id status: type: string title: Status version: type: integer title: Version files: anyOf: - items: $ref: '#/components/schemas/TreeFile' type: array - type: 'null' title: Files error: anyOf: - type: string - type: 'null' title: Error created_at: type: string format: date-time title: Created At completed_at: anyOf: - type: string format: date-time - type: 'null' title: Completed At meta: additionalProperties: true type: object title: Meta type: object required: - tree_id - status - version - files - error - created_at - completed_at - meta title: TreeResponse HTTPValidationError: properties: detail: items: $ref: '#/components/schemas/ValidationError' type: array title: Detail type: object title: HTTPValidationError TreeFile: properties: path: type: string title: Path content: type: string title: Content tier: type: string title: Tier team: anyOf: - type: string - type: 'null' title: Team updated_at: type: string title: Updated At status: anyOf: - type: string - type: 'null' title: Status error: anyOf: - type: string - type: 'null' title: Error provenance: anyOf: - additionalProperties: true type: object - type: 'null' title: Provenance type: object required: - path - content - tier - team - updated_at title: TreeFile ValidationError: properties: loc: items: anyOf: - type: string - type: integer type: array title: Location msg: type: string title: Message type: type: string title: Error Type type: object required: - loc - msg - type title: ValidationError securitySchemes: APIKey: type: http description: >- API Key or JWT User Token. If using an API Key, set the X-As-User header to act as a specific user. A JWT User Token is always scoped to a specific user. scheme: bearer bearerFormat: Bearer AsUser: type: apiKey description: >- Optionally set this header to act as a specific user when using an API Key, equivalent to first exchanging the API Key for a User Token in: header name: X-As-User ````