deapi-ai Client API v2 API

openapi: 3.2.0
info:
  title: deAPI REST Client API v2 API
  description: 'Decentralized AI inference API for image generation, video processing, audio transcription, and more.


    ## Rate limits


    Two windows can apply to a request: a per-minute one (RPM) and a per-day one (RPD). Every

    throttled response — success or 429 — carries the `X-RateLimit-*` headers, so you can pace

    traffic without waiting to be rejected. Each header documents itself: see `components/headers`,

    or the headers listed on any response. What follows is only what a header cannot say about

    itself.


    Windows open on your first request into a bucket and run their full length from that second —

    never to a calendar boundary, in any timezone. That is deliberate: a boundary every account

    shares is a boundary every account can double up on.


    **The headers describe the pool *this* request landed in, and `X-RateLimit-Source` is what

    identifies it — not `X-RateLimit-Limit` alone.** A per-model limit is keyed to the model you

    named, so a request that carried no recognised `model` — rejected at validation, an unknown

    slug, an empty body — was counted against your tier pool, and it is the tier pool the headers

    then describe. The two pools are fully independent: separate minute window, separate day,

    separate `X-RateLimit-Daily-Reset`. This is a consequence of rate limiting running *before*

    validation, which is what keeps malformed traffic from reaching the rest of the API

    uncounted. Compare headers only across responses carrying the same `X-RateLimit-Source`.


    **Buckets are shared in ways worth knowing.** API **v1 and v2 count against the same bucket**,

    so migrating grants no fresh allowance and mixed traffic behaves as one stream. All `*/price`

    and `*/price-calculation` endpoints share a single quote bucket, separate from generation.

    Prompt enhancement (`/v2/prompts/enhancements`) has its own bucket as well, so heavy prompt

    work no longer eats into your image throughput.


    **Counting is exact in sequence, best-effort in parallel.** Sent one after another, your

    requests are counted precisely: the one that crosses the limit is the one that gets 429. Sent

    in parallel, a few beyond the limit can slip through, because the counter is read and then

    incremented as two steps and requests already in flight are not yet visible to one another.

    The excess is bounded by how many of your own requests are in flight at once, and it only

    ever runs in your favour — you are never rejected while below your limit. So do not treat

    `X-RateLimit-Remaining` as a reservation: it is a snapshot, and a request you sent a

    millisecond ago may already have spent what it shows.


    Requests rejected before authentication (HTTP 401) never reach the limiter and carry no

    rate-limit headers at all.'
  contact:
    name: deAPI Support
    url: https://deapi.ai
    email: support@deapi.ai
  version: 0.0.1
servers:
- url: https://api.deapi.ai
  description: Production API Server base URL
security:
- bearerAuth: []
tags:


# --- truncated at 32 KB (293 KB total) ---
# Full source: https://artifacts.apis.io/deapi-ai/openapi/deapi-ai-client-api-v2-api-openapi.yml