> ## Documentation Index > Fetch the complete documentation index at: https://docs.davinci-app.com/llms.txt > Use this file to discover all available pages before exploring further. # Add objects > Adds objects to the running project, opening it if needed. The write goes through the same path an interactive client uses, so parentage, layout, and the broadcast to anyone else in the project all happen as normal. The objects are in memory once this returns; they are in git only after a commit. A response reporting fewer objects than were sent does not happen — the request either applies in full or fails. Every object is checked against the schema for its `type` before anything is written, so one bad object fails the whole request and the project is left untouched. Any type the model defines can be written here; the 400 names what was wrong with each object it refused. ## OpenAPI ````yaml /openapi/davinci-public.v2.yaml post /api/v2/projects/{projectId}/objects openapi: 3.1.0 info: title: Davinci Public API version: 2.0.0 description: > Public Routing Server API contract for Davinci integrations and official SDKs. Most operations live on the canonical `/api/v2/projects` mount and accept a personal access token (`dav_ak_live_…` / `dav_ak_test_…`) or browser access token. Evaluation-run creation is the deliberate exception: it accepts only a `purpose=automation` grant issued to a running Code execution. Project membership and role are checked on every user call, and an API key is additionally bounded by the permission ceiling derived from its scopes — a key can never exceed what its owner can do, and usually does less. Collaboration operations (invitations, membership changes, ownership transfer) are deliberately absent: they require a browser session and are not part of the programmatic surface. ## Two planes Most operations are **control plane**: they run on the Routing Server, take small requests, and answer quickly. A few are **data plane**, marked `x-plane: data`, and go straight to the machine holding your project — the only practical way to move multi-gigabyte files or hold a connection open for half an hour. Data-plane operations use a different host and a different credential. Create a session on a project and it returns both: a `dataPlane.url` to send to and a short-lived `dataPlane.token` (`dav_gr_…`, a *grant*) to send with. A grant reaches exactly one project, carries no more permission than the key that minted it, expires in minutes, and dies when its session closes. It is not interchangeable with an API key in either direction. The data-plane host never names a specific machine, so a project that moves between machines mid-session stays reachable at the same URL. servers: - url: https://davinci-app.com description: Production (control plane) - url: https://davinci-app.com/data description: >- Production (data plane). Serves the operations marked `x-plane: data`, using a session's grant rather than an API key. security: - ApiKeyBearer: [] tags: - name: Projects description: >- Create, inspect, open, close, and delete projects, and manage their attached files. - name: Content description: > Read and write the objects a project is made of. These reach the running project rather than storage, so they see uncommitted work — and so they open the project if it is not already open. - name: Branches description: > Branches, commits, and the history of a single object. A commit captures the running project's state, so these operations need the branch loaded, which they arrange for the caller. - name: Sessions description: > A session opens a project, holds it open, and issues the grant that reaches the data plane. It is the programmatic equivalent of having a project open in a browser tab: while it lives, the project stays loaded. It is also where the agent lives. Send it a prompt, read its status from the session, read the transcript back, and stop a run that is going the wrong way. - name: AgentModels description: > Chat models available to your account. The returned keys are the values accepted by the session message API; availability follows your subscription, tenant, and any profile assigned to your account. - name: Tools description: > Invoke one of the agent's tools yourself, without the agent. Useful when you already know the operation you want and do not need a model to choose it — and when you want a deterministic result rather than an interpreted one. A tool is still held to the permissions of the credential invoking it, so a key cannot reach through a tool to something its scopes exclude. - name: Files description: > Data-plane file transfer. These reach your project's machine directly using a session's grant, which is what allows request bodies far larger than the control plane accepts. - name: Usage description: > What your models cost, broken down by model, project, session, or day. These read the usage ledger, which records one event per completed provider call — not your credit balance, which is `/api/v2/billing`. Usage is reported on an interval rather than per call, so a run that is still going may not be fully counted yet. Every response carries `asOf`, the moment the newest counted event was recorded, so you can see how current a total is instead of guessing. This is separate from `projects:read` on purpose: a key that reads your project data is not thereby allowed to see what you spend. - name: Evaluations description: | Lifecycle for the ephemeral target sandbox an evaluation runs against. Creation is available only to a `purpose=automation` grant issued to a running Code execution, so a sandbox always belongs to code rather than to a person's key. It returns a second, `purpose=evaluation` grant bound to the new sandbox; it never upgrades or replaces the source credential. - name: Tests description: > Asynchronously run an authored Test. The Test executes its linked Code object and applies its native evaluation criteria to derive the verdict. This is one way to start Code, not a prerequisite for anything the Code can do: the same function called directly holds the same authority. - name: Organizations description: Discover organizations available as containers for team planning. - name: Cards description: > Project-scoped agile cards, their index hierarchy, comments, tags, assignees, card dependencies, and design-object references. Project access is checked on every call; an inaccessible project is reported as not found. - name: Teams description: > Organization-scoped team boards, linked projects, workflow columns, sprints, analytics, and card placements. Team visibility is privacy preserving: inaccessible organizations, private teams, and cross-organization ids are reported as not found rather than revealing that they exist. paths: /api/v2/projects/{projectId}/objects: parameters: - $ref: '#/components/parameters/ProjectId' post: tags: - Content summary: Add objects description: > Adds objects to the running project, opening it if needed. The write goes through the same path an interactive client uses, so parentage, layout, and the broadcast to anyone else in the project all happen as normal. The objects are in memory once this returns; they are in git only after a commit. A response reporting fewer objects than were sent does not happen — the request either applies in full or fails. Every object is checked against the schema for its `type` before anything is written, so one bad object fails the whole request and the project is left untouched. Any type the model defines can be written here; the 400 names what was wrong with each object it refused. operationId: addProjectObjects parameters: - $ref: '#/components/parameters/Branch' requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/AddObjectsRequest' responses: '201': description: Objects added. content: application/json: schema: $ref: '#/components/schemas/AddObjectsResponse' '400': description: > Nothing was written. `INVALID_OBJECTS` means the `objects` map itself was missing, empty, or not a map. `INVALID_OBJECT` means at least one object failed its schema: `details.objects` maps each refused id to what is wrong with it, and `details.validTypes` lists every writable type when a `type` was the problem. content: application/json: schema: $ref: '#/components/schemas/ErrorEnvelope' '401': $ref: '#/components/responses/Unauthorized' '403': $ref: '#/components/responses/Forbidden' '404': $ref: '#/components/responses/NotFound' '409': $ref: '#/components/responses/ProjectNotRunning' '429': $ref: '#/components/responses/RateLimited' '500': $ref: '#/components/responses/InternalError' '502': description: > The project accepted the request but applied none of it. Error code is `OBJECTS_NOT_APPLIED`. Nothing was written; the request can be retried. content: application/json: schema: $ref: '#/components/schemas/ErrorEnvelope' '503': $ref: '#/components/responses/ProjectNotReady' security: - ApiKeyBearer: [] x-codeSamples: - lang: typescript label: TypeScript SDK source: | import { DavinciClient } from '@celedon/davinci-sdk'; const client = new DavinciClient({ apiKey: process.env.DAVINCI_API_KEY!, }); const { addedCount } = await client.content.addObjects(projectId, { objects: { [crypto.randomUUID()]: { type: 'requirement', name: 'Dry mass under 500 kg' }, }, }); console.log(addedCount); - lang: python label: Python SDK source: | import os import uuid from davinci_sdk import DavinciClient with DavinciClient(api_key=os.environ["DAVINCI_API_KEY"]) as client: result = client.content.add_objects( project_id, objects={str(uuid.uuid4()): {"type": "requirement", "name": "Dry mass under 500 kg"}}, ) print(result.added_count) components: parameters: ProjectId: name: projectId in: path required: true schema: type: string minLength: 1 description: Project id. May be compound in the form `{projectId}--{branchName}`. Branch: name: branch in: query required: false schema: type: string default: main schemas: AddObjectsRequest: type: object required: - objects properties: objects: type: object minProperties: 1 description: > Objects to add, keyed by the id each should take. A key is an id, so it must be a UUID — mint one per object. Ids must be unique within the project; reusing one overwrites, which is why guessable keys are not accepted. Each body is validated against the schema for its `type`. Fields differ by type, anything the type does not define is refused rather than dropped, and every field is optional except `type` — the model supplies the rest. `tags` is refused here rather than accepted and discarded: creation does not carry them. Assign them once the object exists. additionalProperties: type: object required: - type properties: type: type: string description: > Any object type the model defines: `task`, `requirement`, `part`, `attribute`, `risk`, `test`, `package`, and the rest. A 400 for an unrecognised type lists them all in `details.validTypes`. name: type: string parent: type: string format: uuid description: Overrides `parentId` for this object. additionalProperties: true parentId: type: - string - 'null' format: uuid description: > Parent for objects that do not name one themselves. An id, so a UUID. additionalProperties: false AddObjectsResponse: type: object required: - addedCount - objectIds properties: addedCount: type: integer minimum: 1 objectIds: type: array items: type: string additionalProperties: true ErrorEnvelope: description: > The error shape for every failure on this API, whether it was refused by the credential layer before reaching a domain or by the domain itself. Branch on `code`, which is stable. `message` is for a person reading a log or a dialog and may be reworded. `details` carries fields specific to one failure — a project-limit refusal reports its numbers there — and is absent when there are none. type: object required: - success - error properties: success: type: boolean const: false error: type: object required: - code - message properties: code: type: string message: type: string details: type: object additionalProperties: true additionalProperties: true additionalProperties: true responses: Unauthorized: description: > No credential was supplied, or the supplied credential is malformed, expired, or revoked. A credential that is present but unusable is never downgraded to an anonymous request. content: application/json: schema: $ref: '#/components/schemas/ErrorEnvelope' Forbidden: description: > Authenticated but not authorized. Either the acting user lacks the required resource permission, the key's scope ceiling excludes it, or the endpoint rejects this credential type (`CREDENTIAL_NOT_PERMITTED`). content: application/json: schema: $ref: '#/components/schemas/ErrorEnvelope' NotFound: description: > The resource does not exist in the parent named by the path, or is hidden from the caller. Absence and privacy denial are deliberately indistinguishable so project, organization, and private-team existence cannot be probed. content: application/json: schema: $ref: '#/components/schemas/ErrorEnvelope' ProjectNotRunning: description: > The project stopped running between being opened for this request and the request reaching it. Error code is `PROJECT_NOT_RUNNING`. Retry: the next call opens it again. content: application/json: schema: $ref: '#/components/schemas/ErrorEnvelope' RateLimited: description: Request rate exceeded, either globally or for this key. headers: Retry-After: schema: type: integer minimum: 1 description: Seconds to wait before retrying. content: application/json: schema: $ref: '#/components/schemas/ErrorEnvelope' InternalError: description: Unexpected server error. content: application/json: schema: $ref: '#/components/schemas/ErrorEnvelope' ProjectNotReady: description: > The project could not be opened in time, or no machine is currently available to run it. Error codes are `PROJECT_NOT_READY`, `SERVER_NOT_AVAILABLE`, and `SERVICE_UNAVAILABLE`. Retry after the interval in `Retry-After`. headers: Retry-After: schema: type: integer minimum: 1 description: Seconds to wait before retrying. content: application/json: schema: $ref: '#/components/schemas/ErrorEnvelope' securitySchemes: ApiKeyBearer: type: http scheme: bearer bearerFormat: dav_ak_live_... or dav_ak_test_... x-default: dav_ak_live_your_token description: > Personal access token. The scopes granted at issuance determine both which operations the key may call and the ceiling on the resource permissions it can exercise. Each scope family is a ladder: `projects:manage` implies `projects:write` and `projects:read`; `cards:manage` implies `cards:write` and `cards:read`; and `teams:manage` implies `teams:write` and `teams:read`. These are named API capability bundles, not blanket domain roles: `manage` exposes only the permissions enumerated for that scope and never bypasses the acting user's current role-based access. ````