> ## Documentation Index > Fetch the complete documentation index at: https://docs.kallima.bio/llms.txt > Use this file to discover all available pages before exploring further. # Delete a therapeutic candidate > Delete a therapeutic candidate. **Cascade.** ``variants.candidate_id`` is ``ON DELETE CASCADE``, and ``variant_chains`` / ``jobs`` / pipeline result tables cascade from there — so deleting a candidate drops the full tree underneath it: every variant, every chain row, every submitted pipeline job, and every emitted result. The junction rows in ``candidate_source_antibodies`` and ``candidate_antigens`` also cascade; the linked source antibodies and antigens themselves stay because they're scoped to the project, not the candidate. Callers that want to keep pipeline history should archive the candidate at the application layer (rename, tag, stop submitting against it) rather than deleting. Cost: **write** — burns rate + quota. Does not debit credits. ## OpenAPI ````yaml /api-reference/openapi.json delete /v1/therapeutic-candidates/{candidate_id} openapi: 3.1.0 info: title: Kallima API description: >- Antibody design API — humanization, structure, stability, immunogenicity, complex prediction, and codon optimization. version: 0.1.0 servers: [] security: [] tags: - name: identity description: >- Caller identity and credit balance — use ``GET /v1/me`` to inspect the resolved org, plan, and compute budget before submitting jobs. - name: projects description: >- Projects — top-level containers for source antibodies and therapeutic candidates. - name: source-antibodies description: Source (parental) antibody sequences registered under a project. - name: variants description: >- Variants descended from a therapeutic candidate — the unit of work for pipelines. - name: jobs description: >- Long-running pipeline jobs: humanization, structure, stability, immunogenicity. Submit and poll. Deprecated in favor of resource-per-job-type endpoints (``humanizations`` and the other Phase 3 resources); scheduled for removal in ``/v2``. - name: humanizations description: >- Humanization pipeline runs — typed submit body and typed per-strategy results. First of the Phase 3 resource-per-job-type endpoints; the generic ``/v1/jobs`` shape is deprecated in favor of this. - name: structure-predictions description: >- ImmuneBuilder structure predictions — typed submit body and typed PDB / pLDDT / CDR results. Phase 3 resource-per-job-type endpoint. - name: stability-analyses description: >- Stability analyses — typed submit body and typed thermostability / aggregation / developability scorecard. Phase 3 resource-per-job-type endpoint. - name: immunogenicity-analyses description: >- Immunogenicity analyses — typed submit body and typed MHC-I / MHC-II / B-cell epitope + risk-score results. Phase 3 resource-per-job-type endpoint. - name: uploads description: >- Presigned Supabase Storage slots for caller-supplied files (e.g. antigen PDBs for complex prediction). The API never proxies bytes — clients PUT directly to the returned URL. - name: antigens description: >- Target protein sequences scoped to a project — the docking partner in a complex prediction. Register once, reference by ``antigen_id`` at submit time. - name: complex-predictions description: >- Boltz-2 antibody-antigen complex predictions — typed submit body and typed docked-PDB / iptm / interface-residues results. Phase 3 resource-per-job-type endpoint. Complex runs are long-running (~20–40 min on GPU); always poll, never hold the connection. - name: therapeutic-candidates description: >- Therapeutic candidates — the top-of-lineage object under a project. Creating one auto-creates a baseline variant (``v1``) and its chain rows atomically; pipelines submit against the variant. Junction endpoints manage many-to-many links to source antibodies and antigens. - name: adc-designs description: >- ADC (antibody-drug conjugate) designs — catalog records attaching a linker + payload + conjugation method to a therapeutic candidate. Run the rule-based developability analysis via ``POST /v1/adc-designs/{id}/analysis``; pass ``structure_job_id`` to include SASA-based conjugation-site accessibility. - name: codon-exports description: >- Codon optimization exports — submit a batch of jobs (one per variant), poll until ``variable_cds`` is populated, then download the assembled CDS as FASTA, CSV, or GenBank+ZIP. Requires the Structure plan or above. - name: webhooks description: >- Webhook endpoint registration — register HTTPS URLs to receive signed event deliveries when jobs complete or fail. Signing uses HMAC-SHA256; see ``POST /v1/webhooks`` for verification details. - name: webhook-deliveries description: >- Webhook delivery log — inspect past delivery attempts and manually retry failed ones via ``POST /v1/webhook_deliveries/{id}/retry``. paths: /v1/therapeutic-candidates/{candidate_id}: delete: tags: - therapeutic-candidates summary: Delete a therapeutic candidate description: |- Delete a therapeutic candidate. **Cascade.** ``variants.candidate_id`` is ``ON DELETE CASCADE``, and ``variant_chains`` / ``jobs`` / pipeline result tables cascade from there — so deleting a candidate drops the full tree underneath it: every variant, every chain row, every submitted pipeline job, and every emitted result. The junction rows in ``candidate_source_antibodies`` and ``candidate_antigens`` also cascade; the linked source antibodies and antigens themselves stay because they're scoped to the project, not the candidate. Callers that want to keep pipeline history should archive the candidate at the application layer (rename, tag, stop submitting against it) rather than deleting. Cost: **write** — burns rate + quota. Does not debit credits. operationId: >- delete_therapeutic_candidate_v1_therapeutic_candidates__candidate_id__delete parameters: - name: candidate_id in: path required: true schema: type: string format: uuid title: Candidate Id responses: '204': description: Successful Response '401': description: Missing or invalid API token. content: application/problem+json: schema: $ref: '#/components/schemas/ProblemDetails' '404': description: Resource does not exist in the caller's organization. content: application/problem+json: schema: $ref: '#/components/schemas/ProblemDetails' '422': description: Request failed validation. content: application/problem+json: schema: $ref: '#/components/schemas/ProblemDetails' '429': description: >- Rate limit or monthly write quota exceeded. `Retry-After` holds the number of seconds until the next admitted request. content: application/problem+json: schema: $ref: '#/components/schemas/ProblemDetails' headers: Retry-After: description: Seconds until the caller may retry. Present on 429 responses. schema: type: integer minimum: 1 X-RateLimit-Limit: description: Per-minute rate ceiling for this API token's plan. schema: type: integer X-RateLimit-Remaining: description: Requests remaining in the current rate window. schema: type: integer X-RateLimit-Reset: description: HTTP-date when the rate window resets. schema: type: string format: http-date X-Quota-Limit: description: Monthly write ceiling for this API token's plan. schema: type: integer X-Quota-Remaining: description: Writes remaining in the current monthly window. schema: type: integer X-Quota-Reset: description: >- HTTP-date when the monthly write quota resets (always the 1st of next month UTC). schema: type: string format: http-date security: - HTTPBearer: [] components: schemas: ProblemDetails: additionalProperties: true description: RFC 9457 problem+json body returned by every non-2xx response. example: code: insufficient_credits credit_balance: 0 credit_cost: 1 detail: Humanization costs 1 credit; balance is 0. instance: /v1/jobs request_id: req_01JBX6Y6ZK6N8Q7YJ0F5VX2C3D status: 402 title: Insufficient credits type: https://docs.kallima.bio/errors/insufficient_credits properties: type: description: >- Stable URI identifying the error class. Dereferenceable at docs.kallima.bio/errors/{code}. examples: - https://docs.kallima.bio/errors/insufficient_credits title: Type type: string title: description: Short human-readable summary of the error class. examples: - Insufficient credits title: Title type: string status: description: HTTP status code. Matches the response status line. examples: - 402 title: Status type: integer detail: description: Human-readable explanation with values substituted. examples: - Humanization costs 1 credit; balance is 0. title: Detail type: string instance: description: The specific request URI that failed. examples: - /v1/jobs title: Instance type: string code: description: >- Machine-readable short code. SDKs switch on this, not on `title`. See app.errors.ErrorCode for the full taxonomy. examples: - insufficient_credits title: Code type: string request_id: anyOf: - type: string - type: 'null' default: null description: ULID stamped on every request. Include when contacting support. examples: - req_01JBX6Y6ZK6N8Q7YJ0F5VX2C3D title: Request Id required: - type - title - status - detail - instance - code title: ProblemDetails type: object securitySchemes: HTTPBearer: type: http scheme: bearer ````