> ## Documentation Index
> Fetch the complete documentation index at: https://docs.artbucket.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Ask for access to a portal, or ask its brand team

> Access (`kind` access, the default) is for a `password` or `members` portal. The workspace's admins hear about it. It answers the same whoever asks, and asking twice while one waits is one request. A request section's ask (`kind` asset, review or question) works on any portal, says the `page` and `section` it came from, and needs what reading that page needs (X-Portal-Password or X-Portal-Key, or a member's session), else 401. The `page` must be one the visitor can read and `section` a request section on it; access takes neither.

No key needed.



## OpenAPI

````yaml /openapi.json post /api/v1/portal/{slug}/requests
openapi: 3.1.0
info:
  title: artbucket
  version: '1'
  description: >-
    Agent-first asset management. The web UI is built on this API and nothing
    else, beside signing in at /api/auth. Send `Authorization: Bearer <key>`: a
    key works in one workspace with one scope, and scopes are a ladder: read <
    propose < write < admin. People signed in to the app carry a session cookie
    instead, and their scope is what their grants add up to: on the
    organization, the workspace, or single collections and assets. A scope shown
    as needed on the workspace is also enough on the one collection or asset a
    route acts on. Agents (MCP at POST /api/v1/mcp) usually get `propose`: what
    they add waits for a human.
servers:
  - url: http://localhost:3000
security:
  - bearer: []
  - session: []
  - {}
paths:
  /api/v1/portal/{slug}/requests:
    parameters:
      - name: slug
        in: path
        required: true
        description: The portal's address
        schema:
          type: string
    post:
      summary: Ask for access to a portal, or ask its brand team
      description: >-
        Access (`kind` access, the default) is for a `password` or `members`
        portal. The workspace's admins hear about it. It answers the same
        whoever asks, and asking twice while one waits is one request. A request
        section's ask (`kind` asset, review or question) works on any portal,
        says the `page` and `section` it came from, and needs what reading that
        page needs (X-Portal-Password or X-Portal-Key, or a member's session),
        else 401. The `page` must be one the visitor can read and `section` a
        request section on it; access takes neither.


        No key needed.
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              properties:
                email:
                  type: string
                  maxLength: 320
                  format: email
                  pattern: >-
                    ^(?:[A-Za-z0-9_'+\-]+\.)*[A-Za-z0-9_'+\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\-]*\.)+[A-Za-z]{2,}$
                name:
                  type: string
                  maxLength: 120
                note:
                  description: Who you are and what you need it for
                  type: string
                  maxLength: 2000
                kind:
                  description: >-
                    access when left out; a request section asks for an asset, a
                    review or an answer
                  type: string
                  enum:
                    - access
                    - asset
                    - review
                    - question
                page:
                  description: The page a request section sits on
                  type: string
                  maxLength: 60
                  pattern: ^[a-z0-9]+(-[a-z0-9]+)*$
                section:
                  description: The request section, by id
                  type: string
                  pattern: ^[a-z0-9_-]{1,40}$
              required:
                - email
              additionalProperties: false
      responses:
        '202':
          description: Received
          content:
            application/json:
              schema:
                type: object
                properties:
                  data:
                    type: object
                    properties:
                      received:
                        type: boolean
                        const: true
                    required:
                      - received
                    additionalProperties: false
                required:
                  - data
                additionalProperties: false
        default:
          description: An error
          content:
            application/json:
              schema:
                type: object
                properties:
                  error:
                    type: object
                    properties:
                      code:
                        type: string
                      message:
                        type: string
                      detail: {}
                    required:
                      - code
                      - message
                    additionalProperties: false
                required:
                  - error
                additionalProperties: false
      security: []
components:
  securitySchemes:
    bearer:
      type: http
      scheme: bearer
      description: 'An API key: ab_...'
    session:
      type: apiKey
      in: cookie
      name: better-auth.session_token
      description: Signed in, at /api/auth

````