Deliverd Evidence API

openapi: 3.2.0
info:
  title: Deliverd Dev Evidence API
  version: 1.0.0
  x-refined-note:
  - x-source differs across the merged source definitions and was not carried
  description: 'Operations tagged Evidence across 2 of this provider''s published API definitions: deliverd-dev-openapi.json, deliverd-dev-openapi.yml. Each path carries the servers of the definition it was published in.'
servers:
- url: https://deliverd.dev
  description: 'Deliverd REST API (paths carry the /api/v1 prefix; https://deliverd.dev/llms.txt: "REST API: https://deliverd.dev/api/v1")'
tags:
- name: Evidence
paths:
  /api/v1/evidence/verify:
    post:
      summary: Verify an evidence pack — no credential
      description: Send an evidence pack exactly as the JSON export produced it. The answer says whether its digest recomputes (the file matches itself) and whether its Ed25519 signature checks out against this deployment's current key, published at `/.well-known/deliverd-evidence-key`. Nothing is stored. `deliverd verify ` makes the same check offline, which does not rely on asking us.
      security: []
      requestBody:
        content:
          application/json:
            schema:
              type: object
              additionalProperties: {}
      responses:
        '200':
          description: The verdict
          content:
            application/json:
              schema:
                type: object
                properties:
                  verified:
                    type: boolean
                    description: The digest recomputes and the signature is valid.
                  digestValid:
                    type: boolean
                  signature:
                    type: string
                    enum:
                    - valid
                    - invalid
                    - unsigned
                    - no_key
                    description: '`unsigned`: the pack carries no signature. `no_key`: it is signed but this deployment has no key to check it with. `invalid`: the signature or key id does not match.'
                  keyId:
                    type:
                    - string
                    - 'null'
                    description: The key the pack says it was signed with.
                  currentKeyId:
                    type:
                    - string
                    - 'null'
                    description: The key this deployment signs with now.
                  chainHead:
                    type:
                    - object
                    - 'null'
                    properties:
                      seq:
                        type: integer
                      hash:
                        type: string
                      at:
                        type: string
                    required:
                    - seq
                    - hash
                    - at
                    description: The audit chain head the pack recorded when it was taken.
                required:
                - verified
                - digestValid
                - signature
                - keyId
                - currentKeyId
                - chainHead
      tags:
      - Evidence
      operationId: postApiV1EvidenceVerify
      x-operation-id-source: derived
components:
  securitySchemes:
    bearerAuth:
      type: http
      scheme: bearer
      description: 'API key (dlv_…) created in Settings → API tokens, or an OAuth access token (dlvo_…). Every route below can answer `401 auth_error` — the credential was not accepted — or `403 insufficient_scope`, which is a different thing: the credential is fine and was not issued with the scope this route needs. Reissue it with that scope rather than replacing it with another of the same ones. Older clients may still branch on `auth_error` for both.'
x-refined-from:
- deliverd-dev-openapi.json
- deliverd-dev-openapi.yml