> ## Documentation Index > Fetch the complete documentation index at: https://docs.adaptyvbio.com/llms.txt > Use this file to discover all available pages before exploring further. # Attenuate token > Add restrictions to an existing token without needing the private key. Attenuation is a Biscuit cryptographic feature that allows anyone holding a token to add restriction blocks. The resulting token can only do a subset of what the original token could do—restrictions cannot be removed. # Security Model This endpoint requires the `token:read` capability. 1. **Cryptographic guarantee**: Attenuation can only *reduce* permissions, never expand them. The Biscuit format ensures restriction blocks are append-only and cannot be removed without invalidating the signature. 2. **Self-service by design**: Users can only attenuate tokens they already possess. If you have a token, you can create a weaker version of it—this is analogous to being able to share read-only access to something you own. 3. **No privilege escalation**: The attenuated token inherits all existing restrictions from the source token, plus any new ones added. A read-only token cannot be attenuated into a read-write token. # Use Cases - Create a read-only version of your token for delegation - Restrict a token to specific resources or actions - Generate time-limited tokens for external services - Scope a broad token down to a single organization or project # Timezone All timestamps use UTC in ISO 8601 / RFC 3339 format. # Further Reading For the cryptographic properties of token attenuation, see the [Biscuit documentation](https://doc.biscuitsec.org/). ## OpenAPI ````yaml https://devs.adaptyvbio.com/api/v1/openapi.json post /api/v1/tokens/attenuate openapi: 3.1.0 info: title: Adaptyv Foundry API description: > The Foundry API enables programmatic access to Adaptyv Bio's protein characterization services. ## Getting Started 1. **Obtain an API token** from the [Adaptyv Portal](https://foundry.adaptyvbio.com) or by contacting Adaptyv directly 2. **Authenticate requests** using Bearer token in the Authorization header 3. **Create experiments** to submit protein sequences for characterization 4. **Monitor status** via webhooks or polling the experiment detail endpoint ## Authentication All requests require a Bearer token: ``` Authorization: Bearer ``` Tokens can be attenuated (restricted) to specific organizations or capabilities via the `/tokens` endpoint. ## Pagination List endpoints support offset-based pagination: | Parameter | Description | Default | |-----------|-------------|---------| | `limit` | Maximum items per page | 50 | | `offset` | Number of items to skip | 0 | ## Filtering Most list endpoints support filtering via query parameters using comparison operators: - `equ(field)=value` — equals - `geq(field)=value` — greater than or equal - `gtr(field)=value` — greater than - `leq(field)=value` — less than or equal - `lss(field)=value` — less than Example: `GET /experiments?geq(created_at)=2025-01-01&status=draft` ## Environments | Environment | Base URL | |-------------|----------| | Production | `https://devs.adaptyvbio.com` | ## Support - **Email**: support@adaptyvbio.com - **Documentation**: [docs.adaptyvbio.com](https://docs.adaptyvbio.com) version: 0.0.2 servers: - url: https://devs.adaptyvbio.com/ description: Production API (Public) security: - adaptyv_biscuits_v0: [] tags: - name: experiments description: > Experiments are the core resource for submitting protein sequences to Adaptyv's characterization services. ## Lifecycle Experiments progress through these stages: 1. **Draft** — Initial state for designing your experiment 2. **In Review** — Submitted for validation and quote generation 3. **Quote Sent** — Adaptyv has sent a pricing quote 4. **Waiting for Confirmation** — Quote ready, awaiting acceptance 5. **In Queue** — Confirmed and queued for lab scheduling 6. **Waiting for Materials** — Confirmed, waiting for samples 7. **In Production** — Lab work in progress 8. **Data Analysis** — Characterization complete, processing results 9. **Done** — Results available for download **Canceled** is a terminal state reachable from Draft, In Review, Waiting for Confirmation, or In Queue. ## Experiment Types | Type | Description | Target Required | |------|-------------|-----------------| | `screening` | High-throughput binding assessment | Yes | | `affinity` | Kinetic characterization (KD, kon, koff) | Yes | | `thermostability` | Thermal stability measurement (Tm) | No | | `expression` | Expression yield assessment | No | | `fluorescence` | Fluorescence-based characterization | No | ## Typical Workflow ``` POST /experiments # Create experiment POST /experiments/cost-estimate # Preview pricing POST /experiments/{id}/submit # Submit for review GET /experiments/{id}/quote # Retrieve quote when ready POST /experiments/{id}/quote/confirm # Accept quote GET /experiments/{id} # Monitor progress GET /results?experiment_id={id} # Retrieve results when done ``` ## Related Resources - [Results](#tag/results) — Characterization data from completed experiments - [Sequences](#tag/sequences) — Individual sequences within experiments - [Targets](#tag/targets) — Target proteins for binding experiments - name: feedback description: >- Use this endpoint to give us feedback, report bugs that are not already caught by our observability or request features (or have your agents do it). - name: info description: >- Programmatic discovery and health probes. Anonymous-eligible liveness and database connectivity probes; admin-only assay-type catalog (internal builds). - name: quotes description: >- Stripe quote lifecycle: list, retrieve, confirm, and reject quotes for experiment pricing. - name: results description: > Results contain the characterization data from completed experiments. ## Result Availability Results appear when an experiment reaches the **Done** status. Some experiment types provide partial results during **Data Analysis**. ## Result Types by Experiment | Experiment Type | Result Data | |-----------------|-------------| | Affinity | KD, kon, koff, sensorgrams | | Screening | Binding yes/no, response units | | Thermostability | Tm values, melting curves | | Expression | Yield measurements | ## Downloading Results Use the result `id` to fetch detailed data. Result downloads may include: - Raw sensorgram data - Fitted kinetic parameters - Quality metrics - Summary reports ## Related Resources - [Experiments](#tag/experiments) — Parent resource that produces results - name: sequences description: > Sequences provide read-only access to protein sequences submitted across experiments. ## Sequence Format Sequences are amino acid strings in standard single-letter IUPAC format (e.g., `MKTLLLTLLV...`). ## Sequence Properties | Field | Description | |-------|-------------| | `aa_string` | The amino acid sequence | | `name` | Optional human-readable identifier | | `control` | Whether this is a control sequence | | `metadata` | Structural annotations (tag location, antibody type) | ## Querying Sequences Filter sequences by experiment or other criteria: ``` GET /sequences?experiment_id={id} GET /sequences?name=mAb-001 ``` ## Related Resources - [Experiments](#tag/experiments) — Parent resource containing sequences - name: targets description: > Targets represent the molecules your samples will be tested against in binding experiments (affinity and screening). ## Target Catalog Adaptyv maintains a catalog of pre-validated target proteins with established pricing. Use `selfservice_only=true` to filter for targets with immediate pricing availability. ## Self-Service vs Custom Targets | Category | Description | Pricing | |----------|-------------|---------| | Self-service | Pre-validated catalog targets | Instant quote via cost estimate | | Custom | User-supplied or special request | Requires manual quote | ## Usage 1. Browse targets with `GET /targets?selfservice_only=true` 2. Use the target's `id` when creating an experiment 3. For custom targets, provide a `requested_target` object in the experiment request ## Related Resources - [Experiments](#tag/experiments) — Create experiments using targets - [Cost Estimate](#operation/cost_estimate) — Preview pricing for self-service targets - name: tokens description: > Create restricted versions of your API token for delegation to team members or automated systems. ## Token Attenuation Attenuation **reduces** the permissions of your token—it cannot grant additional access. Attenuated tokens inherit a subset of the parent token's capabilities. ## Restriction Types | Restriction | Effect | |-------------|--------| | Organization | Limit access to specific organizations | | Resource | Limit to specific resource types (experiments, results) | | Action | Limit to specific actions (read, create, update) | | Expiry | Set a shorter expiration time | ## Security Best Practices - Create narrowly-scoped tokens for automated systems - Use short expiration times for temporary access - Revoke tokens promptly when no longer needed - name: updates description: >- Real-time feed of experiment status changes, progress notifications, and operational alerts. Supports cursor-based pagination for efficient polling. - name: whoami description: >- Identify yourself: the organizations your token can access (with the active one marked), your user id, the permissions your token grants, and its expiry. paths: /api/v1/tokens/attenuate: post: tags: - tokens summary: Attenuate token description: >- Add restrictions to an existing token without needing the private key. Attenuation is a Biscuit cryptographic feature that allows anyone holding a token to add restriction blocks. The resulting token can only do a subset of what the original token could do—restrictions cannot be removed. # Security Model This endpoint requires the `token:read` capability. 1. **Cryptographic guarantee**: Attenuation can only *reduce* permissions, never expand them. The Biscuit format ensures restriction blocks are append-only and cannot be removed without invalidating the signature. 2. **Self-service by design**: Users can only attenuate tokens they already possess. If you have a token, you can create a weaker version of it—this is analogous to being able to share read-only access to something you own. 3. **No privilege escalation**: The attenuated token inherits all existing restrictions from the source token, plus any new ones added. A read-only token cannot be attenuated into a read-write token. # Use Cases - Create a read-only version of your token for delegation - Restrict a token to specific resources or actions - Generate time-limited tokens for external services - Scope a broad token down to a single organization or project # Timezone All timestamps use UTC in ISO 8601 / RFC 3339 format. # Further Reading For the cryptographic properties of token attenuation, see the [Biscuit documentation](https://doc.biscuitsec.org/). operationId: attenuate_token requestBody: content: application/json: schema: $ref: '#/components/schemas/AttenuateTokenRequest' required: true responses: '201': description: Token attenuated and persisted content: application/json: schema: $ref: '#/components/schemas/AttenuateTokenResponse' '400': description: Invalid token format or attenuation spec content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '401': description: Invalid or missing authentication token content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '403': description: Insufficient permissions content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' components: schemas: AttenuateTokenRequest: type: object description: >- Request to attenuate (restrict) an existing token. Attenuation is a Biscuit cryptographic feature that adds restriction blocks without needing the private signing key. Any authenticated user can attenuate their tokens to create limited-scope versions for delegation. required: - token - attenuation - name properties: attenuated_parent_token_id: type: - string - 'null' format: uuid description: |- If attenuating an already-attenuated token (chained attenuation), provide the `id` of the parent attenuated token record. Omit when attenuating a root token directly. attenuation: $ref: '#/components/schemas/AttenuationSpec' description: Restrictions to apply to the token. name: type: string description: |- Human-readable label for this attenuated token. Names are not unique — they are purely for display purposes. token: type: string description: >- Existing token string (format: `abs0_{slug}{biscuit_base64}`) to attenuate. AttenuateTokenResponse: type: object description: Response after attenuating a token. required: - token - id properties: id: type: string description: >- Database ID of the attenuated token record (for revocation/management). token: type: string description: 'The attenuated token string. Format: `abs0_{slug}{biscuit_base64}`.' ErrorResponse: type: object description: >- Error response body returned by all endpoints on 4xx/5xx failures. Every error response contains a human-readable message and the request ID for support correlation. The `request_id` is also returned in the `x-request-id` response header. required: - error - request_id properties: error: type: string description: Human-readable error description. example: experiment not found request_id: type: string description: >- Request identifier for support correlation (also in `x-request-id` header). example: req_019462a4-b1c2-7def-8901-23456789abcd AttenuationSpec: type: object description: >- Restriction options for token attenuation. Create limited-scope versions of your token for delegation or integration with external services. All restrictions are additive—the resulting token can only perform a subset of what the original could do. # Quick Options For common use cases, use the convenience flags: - `read_only: true` — Restrict to read operations only (list, read) - `non_destructive: true` — Allow all operations except delete # Fine-Grained Control For precise control, use explicit whitelists: - `allowed_actions` — Permit only specific operations - `allowed_resources` — Permit only specific resource types # Timezone All timestamps use UTC in ISO 8601 / RFC 3339 format. # Examples **Read-only delegation** for a reporting dashboard: ```json { "token": "abs0_FLOWBIO1...", "attenuation": { "read_only": true } } ``` **Time-limited token** expiring in 1 hour: ```json { "token": "abs0_FLOWBIO1...", "attenuation": { "expires_at": "2026-01-20T13:00:00Z" } } ``` **Restrict to specific actions and resources**: ```json { "token": "abs0_FLOWBIO1...", "attenuation": { "allowed_actions": ["list", "read"], "allowed_resources": ["experiment", "result"] } } ``` **Combine multiple restrictions** (read-only, time-limited, org-scoped): ```json { "token": "abs0_FLOWBIO1...", "attenuation": { "read_only": true, "expires_at": "2026-01-21T00:00:00Z", "allowed_org_ids": ["56a01500-1f17-4908-a6a8-472e349e5733"] } } ``` # Further Reading For details on the cryptographic properties of token attenuation, see the [Biscuit documentation](https://doc.biscuitsec.org/). properties: allowed_actions: type: - array - 'null' items: type: string description: >- Explicit list of permitted operations. Values: `list`, `read`, `create`, `update`, `delete`, `issue`, `revoke`, `mint_token` If specified, only these operations are allowed. Applied alongside `read_only` and `non_destructive`; effective permissions are the intersection of all constraints. allowed_org_ids: type: - array - 'null' items: type: string format: uuid description: >- Restrict token to only these organization IDs. The token must already have access to these orgs; attenuation cannot expand access. The token's append-only property enforces this cryptographically. allowed_resources: type: - array - 'null' items: type: string description: >- Explicit list of permitted resource types. Common values: `experiment`, `sequence`, `target`, `result`, `project`, `organization`, `user`, `token`, `webhook`, `update`, `quote`, `invoice`, `billing`, `feedback`, `partner`, `credit`, `usage`, `product`, `info`, `admin`, `policy` If specified, the token can only access these resource types. expires_at: type: - string - 'null' format: date-time description: >- Shorten token expiration to this timestamp (cannot extend past original expiry). Format: ISO 8601 / RFC 3339 (e.g., "2026-01-20T00:00:00Z") non_destructive: type: boolean description: >- Allow all operations except destructive ones (delete). When enabled, the token can list, read, create, and update but not delete. read_only: type: boolean description: |- Restrict to list and read operations only. When enabled, the token cannot create, update, or delete resources. securitySchemes: adaptyv_biscuits_v0: type: http scheme: bearer bearerFormat: Adaptyv Biscuits v0 description: >- Biscuit-based bearer token. Obtain tokens from the Adaptyv Portal or via the `/tokens` endpoint. Tokens encode organization membership and role-based capabilities; the API verifies the token's cryptographic signature and authorization claims before processing requests. Use `/tokens/attenuate` to create restricted tokens for delegation. ````