@deeprelay/sdk 0.2.1 → 0.4.0

package/dist/esm/apis/BillingApi.d.ts

@@ -1,6 +1,6 @@
 /**
  * deeprelay Public Developer API
- * Programmatic API for deeprelay. Authenticate with API keys minted from the dashboard. See https://deeprelay.ai/docs for details.
+ * Programmatic API for deeprelay. Authenticate with API keys minted from the dashboard. See https://deeprelay.ai/docs for details.  Keys minted from the dashboard or `deeprelay login` belong to the Production server, https://api.deeprelay.ai/v1. The Demo server is an internal staging environment with its own key store.  Versioning: `/v1` is the API version. `info.version` is the revision of this `/v1` document, not a separate API.  OpenAI compatibility: chat completions follow the OpenAI request and response shapes, but not every OpenAI parameter is carried. Some are rejected with 400 `unsupported_parameter` and any parameter not declared in this spec is accepted and ignored. The full table is at https://deeprelay.ai/docs/api/inference#openai-compatibility.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@deeprelay.ai
@@ -21,6 +21,7 @@ import { type SubscriptionCheckoutRequest } from '../models/SubscriptionCheckout
 import { type SubscriptionCheckoutSession } from '../models/SubscriptionCheckoutSession';
 import { type SubscriptionPortalRequest } from '../models/SubscriptionPortalRequest';
 import { type SubscriptionPortalSession } from '../models/SubscriptionPortalSession';
+import { type SubscriptionUpgradeRequest } from '../models/SubscriptionUpgradeRequest';
 import { type UpdateSpendingLimitRequest } from '../models/UpdateSpendingLimitRequest';
 export interface CreateCryptoDepositOperationRequest {
     createCryptoDepositRequest: CreateCryptoDepositRequest;
@@ -37,6 +38,9 @@ export interface GetDepositRequest {
 export interface UpdateSpendingLimitOperationRequest {
     updateSpendingLimitRequest: UpdateSpendingLimitRequest;
 }
+export interface UpgradeSubscriptionRequest {
+    subscriptionUpgradeRequest: SubscriptionUpgradeRequest;
+}
 /**
  *
  */
@@ -60,12 +64,12 @@ export declare class BillingApi extends runtime.BaseAPI {
      */
     createSubscriptionCheckoutRequestOpts(requestParameters: CreateSubscriptionCheckoutRequest): Promise<runtime.RequestOpts>;
     /**
-     * Opens a hosted checkout session for the flat tier and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\".  `plan_key`, when sent, pins the plan the client DISPLAYED: an unknown key is a 400 rather than a silent purchase of a different tier. Today there is one tier, so the only accepted value is its key — but sending it is the forward-compatible choice.  One flat tier means at most one subscription per organization: a second checkout while an entitling subscription exists is a 409.
+     * Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses.
      * Start a subscription checkout session
      */
     createSubscriptionCheckoutRaw(requestParameters: CreateSubscriptionCheckoutRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<SubscriptionCheckoutSession>>;
     /**
-     * Opens a hosted checkout session for the flat tier and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\".  `plan_key`, when sent, pins the plan the client DISPLAYED: an unknown key is a 400 rather than a silent purchase of a different tier. Today there is one tier, so the only accepted value is its key — but sending it is the forward-compatible choice.  One flat tier means at most one subscription per organization: a second checkout while an entitling subscription exists is a 409.
+     * Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses.
      * Start a subscription checkout session
      */
     createSubscriptionCheckout(requestParameters?: CreateSubscriptionCheckoutRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<SubscriptionCheckoutSession>;
@@ -130,12 +134,12 @@ export declare class BillingApi extends runtime.BaseAPI {
      */
     getReferralRequestOpts(): Promise<runtime.RequestOpts>;
     /**
-     * Returns the organization\'s shareable referral code and invite link (minting the code on first read), the program terms, the referrer\'s stats, and — when this organization itself signed up through someone else\'s link — its own progress toward the referee reward. Requires the `billing:read` scope. The organization is taken from the authenticated API key, never from a parameter.  The program: share the invite link; when a friend signs up through it and spends `qualify_spend_cents` on inference, the referrer receives `reward_cents` and the friend receives `referee_reward_cents`, both as non-withdrawable credit, after a `hold_days` chargeback hold. The terms ride on the wire so a client never hard-codes the amounts.  `referred` is ABSENT (not null) for an organization nobody referred — key on its presence. This is the same contract the dashboard\'s referral card reads.
+     * Returns the organization\'s shareable referral code and invite link (minting the code on first read), the program terms, the referrer\'s stats, and — when this organization itself signed up through someone else\'s link — its own progress toward the referee reward. Requires the `billing:read` scope. The organization is taken from the authenticated API key, never from a parameter.  The program: share the invite link; when a friend signs up through it and spends `qualify_spend_cents` on inference, the referrer receives `reward_cents` and the friend receives `referee_reward_cents`, both as non-withdrawable credit, after a `hold_days` chargeback hold. The referrer also earns `commission_pct` percent of every real deposit the friend makes, credited as spend-only promotional credit when the deposit clears (`commission_earned_cents`). Program rewards never apply to the subscription. The terms ride on the wire so a client never hard-codes the amounts.  `referred` is ABSENT (not null) for an organization nobody referred — key on its presence. This is the same contract the dashboard\'s referral card reads.
      * Get the org referral code, invite link, terms and stats
      */
     getReferralRaw(initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<Referral>>;
     /**
-     * Returns the organization\'s shareable referral code and invite link (minting the code on first read), the program terms, the referrer\'s stats, and — when this organization itself signed up through someone else\'s link — its own progress toward the referee reward. Requires the `billing:read` scope. The organization is taken from the authenticated API key, never from a parameter.  The program: share the invite link; when a friend signs up through it and spends `qualify_spend_cents` on inference, the referrer receives `reward_cents` and the friend receives `referee_reward_cents`, both as non-withdrawable credit, after a `hold_days` chargeback hold. The terms ride on the wire so a client never hard-codes the amounts.  `referred` is ABSENT (not null) for an organization nobody referred — key on its presence. This is the same contract the dashboard\'s referral card reads.
+     * Returns the organization\'s shareable referral code and invite link (minting the code on first read), the program terms, the referrer\'s stats, and — when this organization itself signed up through someone else\'s link — its own progress toward the referee reward. Requires the `billing:read` scope. The organization is taken from the authenticated API key, never from a parameter.  The program: share the invite link; when a friend signs up through it and spends `qualify_spend_cents` on inference, the referrer receives `reward_cents` and the friend receives `referee_reward_cents`, both as non-withdrawable credit, after a `hold_days` chargeback hold. The referrer also earns `commission_pct` percent of every real deposit the friend makes, credited as spend-only promotional credit when the deposit clears (`commission_earned_cents`). Program rewards never apply to the subscription. The terms ride on the wire so a client never hard-codes the amounts.  `referred` is ABSENT (not null) for an organization nobody referred — key on its presence. This is the same contract the dashboard\'s referral card reads.
      * Get the org referral code, invite link, terms and stats
      */
     getReferral(initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<Referral>;
@@ -158,12 +162,12 @@ export declare class BillingApi extends runtime.BaseAPI {
      */
     getSubscriptionRequestOpts(): Promise<runtime.RequestOpts>;
     /**
-     * Returns the organization\'s flat-tier subscription: whether it is entitled, the current billing period, the plan\'s configured quota, and — for an entitled subscription — consumption against the four limits the server enforces on every request. Requires the `billing:read` scope. The organization is taken from the authenticated API key, never from a parameter.  An organization that never subscribed is NOT an error. It gets 200 with `subscribed: false`, `status: \"none\"` and the quota the plan would provide, so a client can answer \"what does the plan include\" without a second endpoint and without an error path.  Read `subscribed`, not `status`, to decide whether the plan applies: `status` carries the billing provider\'s vocabulary, and the two can disagree — an `active` subscription just past its period end still entitles for a short grace window (renewal-webhook lag), while `past_due` and `canceled` never entitle.  `usage` is present only for an entitled subscription whose meter could be read. An absent `usage` NEVER means \"nothing used\" — reading it as zero would report a full quota to an organization that has none left.  This is the plan\'s meter. For pay-as-you-go credit see `/billing/balance`, for spend against a self-set cap see `/billing/spending-limit`, and for past consumption see `/usage`.
+     * Returns the organization\'s subscription: whether it is entitled, the current billing period, the plan it is on and that plan\'s configured quota, and — for an entitled subscription — consumption against the limits the server enforces on every request. Requires the `billing:read` scope. The organization is taken from the authenticated API key, never from a parameter.  `plan` and `quota` describe the plan the organization IS on (the Base plan for an organization that never subscribed). `plans` lists every plan this deployment offers — Base, then Plus — each with its price and quota, so a client can render an upgrade offer without a second call.  An organization that never subscribed is NOT an error. It gets 200 with `subscribed: false`, `status: \"none\"` and the quota the Base plan would provide, so a client can answer \"what does the plan include\" without a second endpoint and without an error path.  Read `subscribed`, not `status`, to decide whether the plan applies: `status` carries the billing provider\'s vocabulary, and the two can disagree — an `active` subscription just past its period end still entitles for a short grace window (renewal-webhook lag), while `past_due` and `canceled` never entitle.  `usage` is present only for an entitled subscription whose meter could be read. An absent `usage` NEVER means \"nothing used\" — reading it as zero would report a full quota to an organization that has none left.  This is the plan\'s meter. For pay-as-you-go credit see `/billing/balance`, for spend against a self-set cap see `/billing/spending-limit`, and for past consumption see `/usage`.
      * Get the org subscription status and quota usage
      */
     getSubscriptionRaw(initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<Subscription>>;
     /**
-     * Returns the organization\'s flat-tier subscription: whether it is entitled, the current billing period, the plan\'s configured quota, and — for an entitled subscription — consumption against the four limits the server enforces on every request. Requires the `billing:read` scope. The organization is taken from the authenticated API key, never from a parameter.  An organization that never subscribed is NOT an error. It gets 200 with `subscribed: false`, `status: \"none\"` and the quota the plan would provide, so a client can answer \"what does the plan include\" without a second endpoint and without an error path.  Read `subscribed`, not `status`, to decide whether the plan applies: `status` carries the billing provider\'s vocabulary, and the two can disagree — an `active` subscription just past its period end still entitles for a short grace window (renewal-webhook lag), while `past_due` and `canceled` never entitle.  `usage` is present only for an entitled subscription whose meter could be read. An absent `usage` NEVER means \"nothing used\" — reading it as zero would report a full quota to an organization that has none left.  This is the plan\'s meter. For pay-as-you-go credit see `/billing/balance`, for spend against a self-set cap see `/billing/spending-limit`, and for past consumption see `/usage`.
+     * Returns the organization\'s subscription: whether it is entitled, the current billing period, the plan it is on and that plan\'s configured quota, and — for an entitled subscription — consumption against the limits the server enforces on every request. Requires the `billing:read` scope. The organization is taken from the authenticated API key, never from a parameter.  `plan` and `quota` describe the plan the organization IS on (the Base plan for an organization that never subscribed). `plans` lists every plan this deployment offers — Base, then Plus — each with its price and quota, so a client can render an upgrade offer without a second call.  An organization that never subscribed is NOT an error. It gets 200 with `subscribed: false`, `status: \"none\"` and the quota the Base plan would provide, so a client can answer \"what does the plan include\" without a second endpoint and without an error path.  Read `subscribed`, not `status`, to decide whether the plan applies: `status` carries the billing provider\'s vocabulary, and the two can disagree — an `active` subscription just past its period end still entitles for a short grace window (renewal-webhook lag), while `past_due` and `canceled` never entitle.  `usage` is present only for an entitled subscription whose meter could be read. An absent `usage` NEVER means \"nothing used\" — reading it as zero would report a full quota to an organization that has none left.  This is the plan\'s meter. For pay-as-you-go credit see `/billing/balance`, for spend against a self-set cap see `/billing/spending-limit`, and for past consumption see `/usage`.
      * Get the org subscription status and quota usage
      */
     getSubscription(initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<Subscription>;
@@ -195,4 +199,18 @@ export declare class BillingApi extends runtime.BaseAPI {
      * Set the org spending limit
      */
     updateSpendingLimit(requestParameters: UpdateSpendingLimitOperationRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<SpendingLimit>;
+    /**
+     * Creates request options for upgradeSubscription without sending the request
+     */
+    upgradeSubscriptionRequestOpts(requestParameters: UpgradeSubscriptionRequest): Promise<runtime.RequestOpts>;
+    /**
+     * Moves the organization\'s EXISTING subscription onto a bigger plan. Requires the `billing:write` scope AND organization-admin privileges — an upgrade charges the organization\'s card on file.  Unlike checkout, no hosted page is involved: the subscription\'s price is swapped, the new plan\'s FULL price is charged immediately (whenever in the cycle the upgrade happens), and a new billing period starts now. There is no credit for the unused remainder of the old plan\'s period, and the usage meters start from zero on the new plan because every quota window is summed over the current period. The response is the post-upgrade subscription, in the same shape as `/billing/subscription`.  `plan_key` is required and names the target plan (`plus`). The target must be bigger than the plan the organization is on: upgrading to the current plan or to a smaller one is a 409 `not_an_upgrade` — downgrades go through the billing portal. An organization with no entitling subscription gets 409 `not_subscribed` and should use checkout instead. A subscription already set to end at the period close is refused with 409 `subscription_cancelling` (the upgrade would start a new period and move that end date); resume it in the portal first.  If the charge cannot be collected (card declined, no payment method) the call is a 402 `payment_failed` and NOTHING changes — the organization stays on its current plan. Fix the card in the billing portal and retry.
+     * Upgrade the subscription to a bigger plan
+     */
+    upgradeSubscriptionRaw(requestParameters: UpgradeSubscriptionRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<Subscription>>;
+    /**
+     * Moves the organization\'s EXISTING subscription onto a bigger plan. Requires the `billing:write` scope AND organization-admin privileges — an upgrade charges the organization\'s card on file.  Unlike checkout, no hosted page is involved: the subscription\'s price is swapped, the new plan\'s FULL price is charged immediately (whenever in the cycle the upgrade happens), and a new billing period starts now. There is no credit for the unused remainder of the old plan\'s period, and the usage meters start from zero on the new plan because every quota window is summed over the current period. The response is the post-upgrade subscription, in the same shape as `/billing/subscription`.  `plan_key` is required and names the target plan (`plus`). The target must be bigger than the plan the organization is on: upgrading to the current plan or to a smaller one is a 409 `not_an_upgrade` — downgrades go through the billing portal. An organization with no entitling subscription gets 409 `not_subscribed` and should use checkout instead. A subscription already set to end at the period close is refused with 409 `subscription_cancelling` (the upgrade would start a new period and move that end date); resume it in the portal first.  If the charge cannot be collected (card declined, no payment method) the call is a 402 `payment_failed` and NOTHING changes — the organization stays on its current plan. Fix the card in the billing portal and retry.
+     * Upgrade the subscription to a bigger plan
+     */
+    upgradeSubscription(requestParameters: UpgradeSubscriptionRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<Subscription>;
 }

package/dist/esm/apis/BillingApi.js

@@ -2,7 +2,7 @@
 /* eslint-disable */
 /**
  * deeprelay Public Developer API
- * Programmatic API for deeprelay. Authenticate with API keys minted from the dashboard. See https://deeprelay.ai/docs for details.
+ * Programmatic API for deeprelay. Authenticate with API keys minted from the dashboard. See https://deeprelay.ai/docs for details.  Keys minted from the dashboard or `deeprelay login` belong to the Production server, https://api.deeprelay.ai/v1. The Demo server is an internal staging environment with its own key store.  Versioning: `/v1` is the API version. `info.version` is the revision of this `/v1` document, not a separate API.  OpenAI compatibility: chat completions follow the OpenAI request and response shapes, but not every OpenAI parameter is carried. Some are rejected with 400 `unsupported_parameter` and any parameter not declared in this spec is accepted and ignored. The full table is at https://deeprelay.ai/docs/api/inference#openai-compatibility.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@deeprelay.ai
@@ -32,6 +32,7 @@ import { SubscriptionCheckoutRequestToJSON, } from '../models/SubscriptionChecko
 import { SubscriptionCheckoutSessionFromJSON, } from '../models/SubscriptionCheckoutSession';
 import { SubscriptionPortalRequestToJSON, } from '../models/SubscriptionPortalRequest';
 import { SubscriptionPortalSessionFromJSON, } from '../models/SubscriptionPortalSession';
+import { SubscriptionUpgradeRequestToJSON, } from '../models/SubscriptionUpgradeRequest';
 import { UpdateSpendingLimitRequestToJSON, } from '../models/UpdateSpendingLimitRequest';
 /**
  *
@@ -112,7 +113,7 @@ export class BillingApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Opens a hosted checkout session for the flat tier and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\".  `plan_key`, when sent, pins the plan the client DISPLAYED: an unknown key is a 400 rather than a silent purchase of a different tier. Today there is one tier, so the only accepted value is its key — but sending it is the forward-compatible choice.  One flat tier means at most one subscription per organization: a second checkout while an entitling subscription exists is a 409.
+     * Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses.
      * Start a subscription checkout session
      */
     createSubscriptionCheckoutRaw(requestParameters, initOverrides) {
@@ -123,7 +124,7 @@ export class BillingApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Opens a hosted checkout session for the flat tier and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\".  `plan_key`, when sent, pins the plan the client DISPLAYED: an unknown key is a 400 rather than a silent purchase of a different tier. Today there is one tier, so the only accepted value is its key — but sending it is the forward-compatible choice.  One flat tier means at most one subscription per organization: a second checkout while an entitling subscription exists is a 409.
+     * Opens a hosted checkout session for a subscription plan and returns its URL. Requires the `billing:write` scope AND organization-admin privileges — subscribing spends organization money.  This endpoint does NOT subscribe anyone. Checkout is a hosted page that needs a browser and a card, so the caller\'s job is to put the returned URL in front of a human. The subscription becomes active when payment completes, which is not synchronous with this call: poll `/billing/subscription` to confirm.  `success_url` and `cancel_url` are optional and fall back to the deployment\'s configured redirects, which is what lets a command-line client start a purchase without having any URLs of its own. An empty request body is valid and means \"use every default\". When sent, they must be on the deployment\'s dashboard origin, else 422 `validation_failed`.  `plan_key` names the plan to buy: `flat` (Base, the default when the field is omitted) or `plus`. It pins the plan the client DISPLAYED — an unknown key, or a plan this deployment does not offer, is a 400 rather than a silent purchase of a different tier. The `plans` array on `/billing/subscription` lists the accepted keys.  One subscription per organization: a second checkout while an entitling subscription exists is a 409. To move an existing subscription to a bigger plan use `/billing/subscription/upgrade`.  `method` picks how the plan is paid: `card` (dollars, card or Link; the default) or `upi` (rupees, UPI AutoPay, India). On an organization that already subscribes, an explicit `method` in the other currency is a switch, not a second subscription: the link saves the new card or UPI AutoPay mandate (nothing is charged), and once that completes the same plan is moved to the new currency, first charged on the current renewal date (that month is already paid). The answer then carries `switch_to` and `first_charge_at`. A switch is refused (409) within two days of renewal, while the plan is set to cancel, while an upgrade waits on its UPI payment, and in the currency the plan already uses.
      * Start a subscription checkout session
      */
     createSubscriptionCheckout() {
@@ -337,7 +338,7 @@ export class BillingApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Returns the organization\'s shareable referral code and invite link (minting the code on first read), the program terms, the referrer\'s stats, and — when this organization itself signed up through someone else\'s link — its own progress toward the referee reward. Requires the `billing:read` scope. The organization is taken from the authenticated API key, never from a parameter.  The program: share the invite link; when a friend signs up through it and spends `qualify_spend_cents` on inference, the referrer receives `reward_cents` and the friend receives `referee_reward_cents`, both as non-withdrawable credit, after a `hold_days` chargeback hold. The terms ride on the wire so a client never hard-codes the amounts.  `referred` is ABSENT (not null) for an organization nobody referred — key on its presence. This is the same contract the dashboard\'s referral card reads.
+     * Returns the organization\'s shareable referral code and invite link (minting the code on first read), the program terms, the referrer\'s stats, and — when this organization itself signed up through someone else\'s link — its own progress toward the referee reward. Requires the `billing:read` scope. The organization is taken from the authenticated API key, never from a parameter.  The program: share the invite link; when a friend signs up through it and spends `qualify_spend_cents` on inference, the referrer receives `reward_cents` and the friend receives `referee_reward_cents`, both as non-withdrawable credit, after a `hold_days` chargeback hold. The referrer also earns `commission_pct` percent of every real deposit the friend makes, credited as spend-only promotional credit when the deposit clears (`commission_earned_cents`). Program rewards never apply to the subscription. The terms ride on the wire so a client never hard-codes the amounts.  `referred` is ABSENT (not null) for an organization nobody referred — key on its presence. This is the same contract the dashboard\'s referral card reads.
      * Get the org referral code, invite link, terms and stats
      */
     getReferralRaw(initOverrides) {
@@ -348,7 +349,7 @@ export class BillingApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Returns the organization\'s shareable referral code and invite link (minting the code on first read), the program terms, the referrer\'s stats, and — when this organization itself signed up through someone else\'s link — its own progress toward the referee reward. Requires the `billing:read` scope. The organization is taken from the authenticated API key, never from a parameter.  The program: share the invite link; when a friend signs up through it and spends `qualify_spend_cents` on inference, the referrer receives `reward_cents` and the friend receives `referee_reward_cents`, both as non-withdrawable credit, after a `hold_days` chargeback hold. The terms ride on the wire so a client never hard-codes the amounts.  `referred` is ABSENT (not null) for an organization nobody referred — key on its presence. This is the same contract the dashboard\'s referral card reads.
+     * Returns the organization\'s shareable referral code and invite link (minting the code on first read), the program terms, the referrer\'s stats, and — when this organization itself signed up through someone else\'s link — its own progress toward the referee reward. Requires the `billing:read` scope. The organization is taken from the authenticated API key, never from a parameter.  The program: share the invite link; when a friend signs up through it and spends `qualify_spend_cents` on inference, the referrer receives `reward_cents` and the friend receives `referee_reward_cents`, both as non-withdrawable credit, after a `hold_days` chargeback hold. The referrer also earns `commission_pct` percent of every real deposit the friend makes, credited as spend-only promotional credit when the deposit clears (`commission_earned_cents`). Program rewards never apply to the subscription. The terms ride on the wire so a client never hard-codes the amounts.  `referred` is ABSENT (not null) for an organization nobody referred — key on its presence. This is the same contract the dashboard\'s referral card reads.
      * Get the org referral code, invite link, terms and stats
      */
     getReferral(initOverrides) {
@@ -425,7 +426,7 @@ export class BillingApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Returns the organization\'s flat-tier subscription: whether it is entitled, the current billing period, the plan\'s configured quota, and — for an entitled subscription — consumption against the four limits the server enforces on every request. Requires the `billing:read` scope. The organization is taken from the authenticated API key, never from a parameter.  An organization that never subscribed is NOT an error. It gets 200 with `subscribed: false`, `status: \"none\"` and the quota the plan would provide, so a client can answer \"what does the plan include\" without a second endpoint and without an error path.  Read `subscribed`, not `status`, to decide whether the plan applies: `status` carries the billing provider\'s vocabulary, and the two can disagree — an `active` subscription just past its period end still entitles for a short grace window (renewal-webhook lag), while `past_due` and `canceled` never entitle.  `usage` is present only for an entitled subscription whose meter could be read. An absent `usage` NEVER means \"nothing used\" — reading it as zero would report a full quota to an organization that has none left.  This is the plan\'s meter. For pay-as-you-go credit see `/billing/balance`, for spend against a self-set cap see `/billing/spending-limit`, and for past consumption see `/usage`.
+     * Returns the organization\'s subscription: whether it is entitled, the current billing period, the plan it is on and that plan\'s configured quota, and — for an entitled subscription — consumption against the limits the server enforces on every request. Requires the `billing:read` scope. The organization is taken from the authenticated API key, never from a parameter.  `plan` and `quota` describe the plan the organization IS on (the Base plan for an organization that never subscribed). `plans` lists every plan this deployment offers — Base, then Plus — each with its price and quota, so a client can render an upgrade offer without a second call.  An organization that never subscribed is NOT an error. It gets 200 with `subscribed: false`, `status: \"none\"` and the quota the Base plan would provide, so a client can answer \"what does the plan include\" without a second endpoint and without an error path.  Read `subscribed`, not `status`, to decide whether the plan applies: `status` carries the billing provider\'s vocabulary, and the two can disagree — an `active` subscription just past its period end still entitles for a short grace window (renewal-webhook lag), while `past_due` and `canceled` never entitle.  `usage` is present only for an entitled subscription whose meter could be read. An absent `usage` NEVER means \"nothing used\" — reading it as zero would report a full quota to an organization that has none left.  This is the plan\'s meter. For pay-as-you-go credit see `/billing/balance`, for spend against a self-set cap see `/billing/spending-limit`, and for past consumption see `/usage`.
      * Get the org subscription status and quota usage
      */
     getSubscriptionRaw(initOverrides) {
@@ -436,7 +437,7 @@ export class BillingApi extends runtime.BaseAPI {
         });
     }
     /**
-     * Returns the organization\'s flat-tier subscription: whether it is entitled, the current billing period, the plan\'s configured quota, and — for an entitled subscription — consumption against the four limits the server enforces on every request. Requires the `billing:read` scope. The organization is taken from the authenticated API key, never from a parameter.  An organization that never subscribed is NOT an error. It gets 200 with `subscribed: false`, `status: \"none\"` and the quota the plan would provide, so a client can answer \"what does the plan include\" without a second endpoint and without an error path.  Read `subscribed`, not `status`, to decide whether the plan applies: `status` carries the billing provider\'s vocabulary, and the two can disagree — an `active` subscription just past its period end still entitles for a short grace window (renewal-webhook lag), while `past_due` and `canceled` never entitle.  `usage` is present only for an entitled subscription whose meter could be read. An absent `usage` NEVER means \"nothing used\" — reading it as zero would report a full quota to an organization that has none left.  This is the plan\'s meter. For pay-as-you-go credit see `/billing/balance`, for spend against a self-set cap see `/billing/spending-limit`, and for past consumption see `/usage`.
+     * Returns the organization\'s subscription: whether it is entitled, the current billing period, the plan it is on and that plan\'s configured quota, and — for an entitled subscription — consumption against the limits the server enforces on every request. Requires the `billing:read` scope. The organization is taken from the authenticated API key, never from a parameter.  `plan` and `quota` describe the plan the organization IS on (the Base plan for an organization that never subscribed). `plans` lists every plan this deployment offers — Base, then Plus — each with its price and quota, so a client can render an upgrade offer without a second call.  An organization that never subscribed is NOT an error. It gets 200 with `subscribed: false`, `status: \"none\"` and the quota the Base plan would provide, so a client can answer \"what does the plan include\" without a second endpoint and without an error path.  Read `subscribed`, not `status`, to decide whether the plan applies: `status` carries the billing provider\'s vocabulary, and the two can disagree — an `active` subscription just past its period end still entitles for a short grace window (renewal-webhook lag), while `past_due` and `canceled` never entitle.  `usage` is present only for an entitled subscription whose meter could be read. An absent `usage` NEVER means \"nothing used\" — reading it as zero would report a full quota to an organization that has none left.  This is the plan\'s meter. For pay-as-you-go credit see `/billing/balance`, for spend against a self-set cap see `/billing/spending-limit`, and for past consumption see `/usage`.
      * Get the org subscription status and quota usage
      */
     getSubscription(initOverrides) {
@@ -538,4 +539,53 @@ export class BillingApi extends runtime.BaseAPI {
             return yield response.value();
         });
     }
+    /**
+     * Creates request options for upgradeSubscription without sending the request
+     */
+    upgradeSubscriptionRequestOpts(requestParameters) {
+        return __awaiter(this, void 0, void 0, function* () {
+            if (requestParameters['subscriptionUpgradeRequest'] == null) {
+                throw new runtime.RequiredError('subscriptionUpgradeRequest', 'Required parameter "subscriptionUpgradeRequest" was null or undefined when calling upgradeSubscription().');
+            }
+            const queryParameters = {};
+            const headerParameters = {};
+            headerParameters['Content-Type'] = 'application/json';
+            if (this.configuration && this.configuration.accessToken) {
+                const token = this.configuration.accessToken;
+                const tokenString = yield token("bearerAuth", []);
+                if (tokenString) {
+                    headerParameters["Authorization"] = `Bearer ${tokenString}`;
+                }
+            }
+            let urlPath = `/billing/subscription/upgrade`;
+            return {
+                path: urlPath,
+                method: 'POST',
+                headers: headerParameters,
+                query: queryParameters,
+                body: SubscriptionUpgradeRequestToJSON(requestParameters['subscriptionUpgradeRequest']),
+            };
+        });
+    }
+    /**
+     * Moves the organization\'s EXISTING subscription onto a bigger plan. Requires the `billing:write` scope AND organization-admin privileges — an upgrade charges the organization\'s card on file.  Unlike checkout, no hosted page is involved: the subscription\'s price is swapped, the new plan\'s FULL price is charged immediately (whenever in the cycle the upgrade happens), and a new billing period starts now. There is no credit for the unused remainder of the old plan\'s period, and the usage meters start from zero on the new plan because every quota window is summed over the current period. The response is the post-upgrade subscription, in the same shape as `/billing/subscription`.  `plan_key` is required and names the target plan (`plus`). The target must be bigger than the plan the organization is on: upgrading to the current plan or to a smaller one is a 409 `not_an_upgrade` — downgrades go through the billing portal. An organization with no entitling subscription gets 409 `not_subscribed` and should use checkout instead. A subscription already set to end at the period close is refused with 409 `subscription_cancelling` (the upgrade would start a new period and move that end date); resume it in the portal first.  If the charge cannot be collected (card declined, no payment method) the call is a 402 `payment_failed` and NOTHING changes — the organization stays on its current plan. Fix the card in the billing portal and retry.
+     * Upgrade the subscription to a bigger plan
+     */
+    upgradeSubscriptionRaw(requestParameters, initOverrides) {
+        return __awaiter(this, void 0, void 0, function* () {
+            const requestOptions = yield this.upgradeSubscriptionRequestOpts(requestParameters);
+            const response = yield this.request(requestOptions, initOverrides);
+            return new runtime.JSONApiResponse(response, (jsonValue) => SubscriptionFromJSON(jsonValue));
+        });
+    }
+    /**
+     * Moves the organization\'s EXISTING subscription onto a bigger plan. Requires the `billing:write` scope AND organization-admin privileges — an upgrade charges the organization\'s card on file.  Unlike checkout, no hosted page is involved: the subscription\'s price is swapped, the new plan\'s FULL price is charged immediately (whenever in the cycle the upgrade happens), and a new billing period starts now. There is no credit for the unused remainder of the old plan\'s period, and the usage meters start from zero on the new plan because every quota window is summed over the current period. The response is the post-upgrade subscription, in the same shape as `/billing/subscription`.  `plan_key` is required and names the target plan (`plus`). The target must be bigger than the plan the organization is on: upgrading to the current plan or to a smaller one is a 409 `not_an_upgrade` — downgrades go through the billing portal. An organization with no entitling subscription gets 409 `not_subscribed` and should use checkout instead. A subscription already set to end at the period close is refused with 409 `subscription_cancelling` (the upgrade would start a new period and move that end date); resume it in the portal first.  If the charge cannot be collected (card declined, no payment method) the call is a 402 `payment_failed` and NOTHING changes — the organization stays on its current plan. Fix the card in the billing portal and retry.
+     * Upgrade the subscription to a bigger plan
+     */
+    upgradeSubscription(requestParameters, initOverrides) {
+        return __awaiter(this, void 0, void 0, function* () {
+            const response = yield this.upgradeSubscriptionRaw(requestParameters, initOverrides);
+            return yield response.value();
+        });
+    }
 }

package/dist/esm/apis/InferenceApi.d.ts

@@ -1,6 +1,6 @@
 /**
  * deeprelay Public Developer API
- * Programmatic API for deeprelay. Authenticate with API keys minted from the dashboard. See https://deeprelay.ai/docs for details.
+ * Programmatic API for deeprelay. Authenticate with API keys minted from the dashboard. See https://deeprelay.ai/docs for details.  Keys minted from the dashboard or `deeprelay login` belong to the Production server, https://api.deeprelay.ai/v1. The Demo server is an internal staging environment with its own key store.  Versioning: `/v1` is the API version. `info.version` is the revision of this `/v1` document, not a separate API.  OpenAI compatibility: chat completions follow the OpenAI request and response shapes, but not every OpenAI parameter is carried. Some are rejected with 400 `unsupported_parameter` and any parameter not declared in this spec is accepted and ignored. The full table is at https://deeprelay.ai/docs/api/inference#openai-compatibility.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@deeprelay.ai
@@ -27,17 +27,21 @@ export interface CancelVideoRequest {
 }
 export interface CreateChatCompletionRequest {
     chatCompletionRequest: ChatCompletionRequest;
+    xClientRequestId?: string;
 }
 export interface CreateEmbeddingsRequest {
     embeddingsRequest: EmbeddingsRequest;
+    xClientRequestId?: string;
 }
 export interface CreateImageRequest {
     imagesGenerationsRequest: ImagesGenerationsRequest;
     idempotencyKey?: string;
+    xClientRequestId?: string;
 }
 export interface CreateVideoRequest {
     videoCreateRequest: VideoCreateRequest;
     idempotencyKey?: string;
+    xClientRequestId?: string;
 }
 export interface GetModelRequest {
     id: string;
@@ -53,6 +57,7 @@ export interface InferencePreflightRequest {
 }
 export interface ListModelsRequest {
     modality?: ListModelsModalityEnum;
+    ifNoneMatch?: string;
 }
 export interface ListVideosRequest {
     after?: string;
@@ -79,10 +84,12 @@ export declare class InferenceApi extends runtime.BaseAPI {
      */
     createChatCompletionRequestOpts(requestParameters: CreateChatCompletionRequest): Promise<runtime.RequestOpts>;
     /**
+     * OpenAI-compatible chat completion. Parameters fall into three groups:  - **Semantic parameters are gated per model.** `response_format`,   `tools`/`tool_choice`, `logprobs`/`top_logprobs` and `image_url`   content parts are sent only to a model whose `/v1/models` entry   lists the capability in `supported_parameters` (`vision` for   images). A model without it returns 400 `unsupported_parameter`   whose message names the models that do support it. When the model   supports the parameter but none of its currently routable upstreams   does, the request fails with 503 `upstream_unavailable` rather than   being silently degraded. - **Hints are forwarded or dropped, never rejected.**   `reasoning_effort`, `presence_penalty`, `frequency_penalty`, `seed`   and `parallel_tool_calls` are forwarded to an upstream that accepts   them and otherwise dropped. Every drop is reported in the   `x-deeprelay-ignored-params` response header. - **Rejected everywhere.** `logit_bias` and `function_call` return   400 `unsupported_parameter`; `input_audio` and `file` content parts   return 400 `unsupported_content_part`.  A non-strict `json_schema` sent to a model that can only guarantee JSON is served as `json_object` and reported as `response_format:downgraded`; a strict one is rejected. A `json_schema` over 64 KiB or nested deeper than 32 levels returns 400 `unsupported_parameter` (param `response_format`). An upstream rejection of a request the relay accepted returns 400 `upstream_rejected_request`. A non-chat model id returns 404 `model_not_found`. The request body is capped at 32 MiB (413 `request_too_large`).  Every successful response carries `usage.cost` and `usage.cost_details` (on a stream, only in the final usage chunk). See https://deeprelay.ai/docs/api/inference#openai-compatibility.
      * Create a chat completion (OpenAI-compatible)
      */
     createChatCompletionRaw(requestParameters: CreateChatCompletionRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<ChatCompletionResponse>>;
     /**
+     * OpenAI-compatible chat completion. Parameters fall into three groups:  - **Semantic parameters are gated per model.** `response_format`,   `tools`/`tool_choice`, `logprobs`/`top_logprobs` and `image_url`   content parts are sent only to a model whose `/v1/models` entry   lists the capability in `supported_parameters` (`vision` for   images). A model without it returns 400 `unsupported_parameter`   whose message names the models that do support it. When the model   supports the parameter but none of its currently routable upstreams   does, the request fails with 503 `upstream_unavailable` rather than   being silently degraded. - **Hints are forwarded or dropped, never rejected.**   `reasoning_effort`, `presence_penalty`, `frequency_penalty`, `seed`   and `parallel_tool_calls` are forwarded to an upstream that accepts   them and otherwise dropped. Every drop is reported in the   `x-deeprelay-ignored-params` response header. - **Rejected everywhere.** `logit_bias` and `function_call` return   400 `unsupported_parameter`; `input_audio` and `file` content parts   return 400 `unsupported_content_part`.  A non-strict `json_schema` sent to a model that can only guarantee JSON is served as `json_object` and reported as `response_format:downgraded`; a strict one is rejected. A `json_schema` over 64 KiB or nested deeper than 32 levels returns 400 `unsupported_parameter` (param `response_format`). An upstream rejection of a request the relay accepted returns 400 `upstream_rejected_request`. A non-chat model id returns 404 `model_not_found`. The request body is capped at 32 MiB (413 `request_too_large`).  Every successful response carries `usage.cost` and `usage.cost_details` (on a stream, only in the final usage chunk). See https://deeprelay.ai/docs/api/inference#openai-compatibility.
      * Create a chat completion (OpenAI-compatible)
      */
     createChatCompletion(requestParameters: CreateChatCompletionRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<ChatCompletionResponse>;
@@ -133,10 +140,12 @@ export declare class InferenceApi extends runtime.BaseAPI {
      */
     getModelRequestOpts(requestParameters: GetModelRequest): Promise<runtime.RequestOpts>;
     /**
+     * A key with a model allowlist gets 403 `model_not_allowed_for_key` for a model off its list, and the same 403 for an id that does not exist.
      * Get a specific model (OpenAI-compatible)
      */
     getModelRaw(requestParameters: GetModelRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<Model>>;
     /**
+     * A key with a model allowlist gets 403 `model_not_allowed_for_key` for a model off its list, and the same 403 for an id that does not exist.
      * Get a specific model (OpenAI-compatible)
      */
     getModel(requestParameters: GetModelRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<Model>;
@@ -185,10 +194,12 @@ export declare class InferenceApi extends runtime.BaseAPI {
      */
     listModelsRequestOpts(requestParameters: ListModelsRequest): Promise<runtime.RequestOpts>;
     /**
+     * Works with or without an API key, and returns the same body either way. Without a key the response is publicly cacheable (`Cache-Control: public, max-age=60`), carries a strong `ETag` (send `If-None-Match` to get a 304), and is rate-limited per client IP (429 `rate_limit_exceeded` with Retry-After). With a key it is `Cache-Control: private` and counts against the key\'s rate limit; an invalid key returns 401, it does not fall back to anonymous access. Error responses are `no-store`.  Each entry\'s `supported_parameters` is backed by live capability probes of the model\'s upstreams: it is the list to check before sending a gated parameter (`response_format`, `structured_outputs`, `logprobs`, `tools`, `vision`, ...).  One exception to \"the same body\": a key with a model allowlist (`allowed_models`) sees only the models on its list.  Each entry may carry a `metrics` object (always the last key): measured time to first token, decode rate and success rate over a rolling window of deeprelay customer traffic. Below the sample minimum `insufficient_data` is true and the figure is omitted, never zero.
      * List available models (OpenAI-compatible)
      */
     listModelsRaw(requestParameters: ListModelsRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<ModelList>>;
     /**
+     * Works with or without an API key, and returns the same body either way. Without a key the response is publicly cacheable (`Cache-Control: public, max-age=60`), carries a strong `ETag` (send `If-None-Match` to get a 304), and is rate-limited per client IP (429 `rate_limit_exceeded` with Retry-After). With a key it is `Cache-Control: private` and counts against the key\'s rate limit; an invalid key returns 401, it does not fall back to anonymous access. Error responses are `no-store`.  Each entry\'s `supported_parameters` is backed by live capability probes of the model\'s upstreams: it is the list to check before sending a gated parameter (`response_format`, `structured_outputs`, `logprobs`, `tools`, `vision`, ...).  One exception to \"the same body\": a key with a model allowlist (`allowed_models`) sees only the models on its list.  Each entry may carry a `metrics` object (always the last key): measured time to first token, decode rate and success rate over a rolling window of deeprelay customer traffic. Below the sample minimum `insufficient_data` is true and the figure is omitted, never zero.
      * List available models (OpenAI-compatible)
      */
     listModels(requestParameters?: ListModelsRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<ModelList>;

package/dist/esm/apis/InferenceApi.js

@@ -2,7 +2,7 @@
 /* eslint-disable */
 /**
  * deeprelay Public Developer API
- * Programmatic API for deeprelay. Authenticate with API keys minted from the dashboard. See https://deeprelay.ai/docs for details.
+ * Programmatic API for deeprelay. Authenticate with API keys minted from the dashboard. See https://deeprelay.ai/docs for details.  Keys minted from the dashboard or `deeprelay login` belong to the Production server, https://api.deeprelay.ai/v1. The Demo server is an internal staging environment with its own key store.  Versioning: `/v1` is the API version. `info.version` is the revision of this `/v1` document, not a separate API.  OpenAI compatibility: chat completions follow the OpenAI request and response shapes, but not every OpenAI parameter is carried. Some are rejected with 400 `unsupported_parameter` and any parameter not declared in this spec is accepted and ignored. The full table is at https://deeprelay.ai/docs/api/inference#openai-compatibility.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@deeprelay.ai
@@ -94,6 +94,9 @@ export class InferenceApi extends runtime.BaseAPI {
             const queryParameters = {};
             const headerParameters = {};
             headerParameters['Content-Type'] = 'application/json';
+            if (requestParameters['xClientRequestId'] != null) {
+                headerParameters['X-Client-Request-Id'] = String(requestParameters['xClientRequestId']);
+            }
             if (this.configuration && this.configuration.accessToken) {
                 const token = this.configuration.accessToken;
                 const tokenString = yield token("bearerAuth", []);
@@ -112,6 +115,7 @@ export class InferenceApi extends runtime.BaseAPI {
         });
     }
     /**
+     * OpenAI-compatible chat completion. Parameters fall into three groups:  - **Semantic parameters are gated per model.** `response_format`,   `tools`/`tool_choice`, `logprobs`/`top_logprobs` and `image_url`   content parts are sent only to a model whose `/v1/models` entry   lists the capability in `supported_parameters` (`vision` for   images). A model without it returns 400 `unsupported_parameter`   whose message names the models that do support it. When the model   supports the parameter but none of its currently routable upstreams   does, the request fails with 503 `upstream_unavailable` rather than   being silently degraded. - **Hints are forwarded or dropped, never rejected.**   `reasoning_effort`, `presence_penalty`, `frequency_penalty`, `seed`   and `parallel_tool_calls` are forwarded to an upstream that accepts   them and otherwise dropped. Every drop is reported in the   `x-deeprelay-ignored-params` response header. - **Rejected everywhere.** `logit_bias` and `function_call` return   400 `unsupported_parameter`; `input_audio` and `file` content parts   return 400 `unsupported_content_part`.  A non-strict `json_schema` sent to a model that can only guarantee JSON is served as `json_object` and reported as `response_format:downgraded`; a strict one is rejected. A `json_schema` over 64 KiB or nested deeper than 32 levels returns 400 `unsupported_parameter` (param `response_format`). An upstream rejection of a request the relay accepted returns 400 `upstream_rejected_request`. A non-chat model id returns 404 `model_not_found`. The request body is capped at 32 MiB (413 `request_too_large`).  Every successful response carries `usage.cost` and `usage.cost_details` (on a stream, only in the final usage chunk). See https://deeprelay.ai/docs/api/inference#openai-compatibility.
      * Create a chat completion (OpenAI-compatible)
      */
     createChatCompletionRaw(requestParameters, initOverrides) {
@@ -122,6 +126,7 @@ export class InferenceApi extends runtime.BaseAPI {
         });
     }
     /**
+     * OpenAI-compatible chat completion. Parameters fall into three groups:  - **Semantic parameters are gated per model.** `response_format`,   `tools`/`tool_choice`, `logprobs`/`top_logprobs` and `image_url`   content parts are sent only to a model whose `/v1/models` entry   lists the capability in `supported_parameters` (`vision` for   images). A model without it returns 400 `unsupported_parameter`   whose message names the models that do support it. When the model   supports the parameter but none of its currently routable upstreams   does, the request fails with 503 `upstream_unavailable` rather than   being silently degraded. - **Hints are forwarded or dropped, never rejected.**   `reasoning_effort`, `presence_penalty`, `frequency_penalty`, `seed`   and `parallel_tool_calls` are forwarded to an upstream that accepts   them and otherwise dropped. Every drop is reported in the   `x-deeprelay-ignored-params` response header. - **Rejected everywhere.** `logit_bias` and `function_call` return   400 `unsupported_parameter`; `input_audio` and `file` content parts   return 400 `unsupported_content_part`.  A non-strict `json_schema` sent to a model that can only guarantee JSON is served as `json_object` and reported as `response_format:downgraded`; a strict one is rejected. A `json_schema` over 64 KiB or nested deeper than 32 levels returns 400 `unsupported_parameter` (param `response_format`). An upstream rejection of a request the relay accepted returns 400 `upstream_rejected_request`. A non-chat model id returns 404 `model_not_found`. The request body is capped at 32 MiB (413 `request_too_large`).  Every successful response carries `usage.cost` and `usage.cost_details` (on a stream, only in the final usage chunk). See https://deeprelay.ai/docs/api/inference#openai-compatibility.
      * Create a chat completion (OpenAI-compatible)
      */
     createChatCompletion(requestParameters, initOverrides) {
@@ -141,6 +146,9 @@ export class InferenceApi extends runtime.BaseAPI {
             const queryParameters = {};
             const headerParameters = {};
             headerParameters['Content-Type'] = 'application/json';
+            if (requestParameters['xClientRequestId'] != null) {
+                headerParameters['X-Client-Request-Id'] = String(requestParameters['xClientRequestId']);
+            }
             if (this.configuration && this.configuration.accessToken) {
                 const token = this.configuration.accessToken;
                 const tokenString = yield token("bearerAuth", []);
@@ -193,6 +201,9 @@ export class InferenceApi extends runtime.BaseAPI {
             if (requestParameters['idempotencyKey'] != null) {
                 headerParameters['Idempotency-Key'] = String(requestParameters['idempotencyKey']);
             }
+            if (requestParameters['xClientRequestId'] != null) {
+                headerParameters['X-Client-Request-Id'] = String(requestParameters['xClientRequestId']);
+            }
             if (this.configuration && this.configuration.accessToken) {
                 const token = this.configuration.accessToken;
                 const tokenString = yield token("bearerAuth", []);
@@ -245,6 +256,9 @@ export class InferenceApi extends runtime.BaseAPI {
             if (requestParameters['idempotencyKey'] != null) {
                 headerParameters['Idempotency-Key'] = String(requestParameters['idempotencyKey']);
             }
+            if (requestParameters['xClientRequestId'] != null) {
+                headerParameters['X-Client-Request-Id'] = String(requestParameters['xClientRequestId']);
+            }
             if (this.configuration && this.configuration.accessToken) {
                 const token = this.configuration.accessToken;
                 const tokenString = yield token("bearerAuth", []);
@@ -311,6 +325,7 @@ export class InferenceApi extends runtime.BaseAPI {
         });
     }
     /**
+     * A key with a model allowlist gets 403 `model_not_allowed_for_key` for a model off its list, and the same 403 for an id that does not exist.
      * Get a specific model (OpenAI-compatible)
      */
     getModelRaw(requestParameters, initOverrides) {
@@ -321,6 +336,7 @@ export class InferenceApi extends runtime.BaseAPI {
         });
     }
     /**
+     * A key with a model allowlist gets 403 `model_not_allowed_for_key` for a model off its list, and the same 403 for an id that does not exist.
      * Get a specific model (OpenAI-compatible)
      */
     getModel(requestParameters, initOverrides) {
@@ -483,6 +499,9 @@ export class InferenceApi extends runtime.BaseAPI {
                 queryParameters['modality'] = requestParameters['modality'];
             }
             const headerParameters = {};
+            if (requestParameters['ifNoneMatch'] != null) {
+                headerParameters['If-None-Match'] = String(requestParameters['ifNoneMatch']);
+            }
             if (this.configuration && this.configuration.accessToken) {
                 const token = this.configuration.accessToken;
                 const tokenString = yield token("bearerAuth", []);
@@ -500,6 +519,7 @@ export class InferenceApi extends runtime.BaseAPI {
         });
     }
     /**
+     * Works with or without an API key, and returns the same body either way. Without a key the response is publicly cacheable (`Cache-Control: public, max-age=60`), carries a strong `ETag` (send `If-None-Match` to get a 304), and is rate-limited per client IP (429 `rate_limit_exceeded` with Retry-After). With a key it is `Cache-Control: private` and counts against the key\'s rate limit; an invalid key returns 401, it does not fall back to anonymous access. Error responses are `no-store`.  Each entry\'s `supported_parameters` is backed by live capability probes of the model\'s upstreams: it is the list to check before sending a gated parameter (`response_format`, `structured_outputs`, `logprobs`, `tools`, `vision`, ...).  One exception to \"the same body\": a key with a model allowlist (`allowed_models`) sees only the models on its list.  Each entry may carry a `metrics` object (always the last key): measured time to first token, decode rate and success rate over a rolling window of deeprelay customer traffic. Below the sample minimum `insufficient_data` is true and the figure is omitted, never zero.
      * List available models (OpenAI-compatible)
      */
     listModelsRaw(requestParameters, initOverrides) {
@@ -510,6 +530,7 @@ export class InferenceApi extends runtime.BaseAPI {
         });
     }
     /**
+     * Works with or without an API key, and returns the same body either way. Without a key the response is publicly cacheable (`Cache-Control: public, max-age=60`), carries a strong `ETag` (send `If-None-Match` to get a 304), and is rate-limited per client IP (429 `rate_limit_exceeded` with Retry-After). With a key it is `Cache-Control: private` and counts against the key\'s rate limit; an invalid key returns 401, it does not fall back to anonymous access. Error responses are `no-store`.  Each entry\'s `supported_parameters` is backed by live capability probes of the model\'s upstreams: it is the list to check before sending a gated parameter (`response_format`, `structured_outputs`, `logprobs`, `tools`, `vision`, ...).  One exception to \"the same body\": a key with a model allowlist (`allowed_models`) sees only the models on its list.  Each entry may carry a `metrics` object (always the last key): measured time to first token, decode rate and success rate over a rolling window of deeprelay customer traffic. Below the sample minimum `insufficient_data` is true and the figure is omitted, never zero.
      * List available models (OpenAI-compatible)
      */
     listModels() {

package/dist/esm/apis/MetaApi.d.ts

@@ -1,6 +1,6 @@
 /**
  * deeprelay Public Developer API
- * Programmatic API for deeprelay. Authenticate with API keys minted from the dashboard. See https://deeprelay.ai/docs for details.
+ * Programmatic API for deeprelay. Authenticate with API keys minted from the dashboard. See https://deeprelay.ai/docs for details.  Keys minted from the dashboard or `deeprelay login` belong to the Production server, https://api.deeprelay.ai/v1. The Demo server is an internal staging environment with its own key store.  Versioning: `/v1` is the API version. `info.version` is the revision of this `/v1` document, not a separate API.  OpenAI compatibility: chat completions follow the OpenAI request and response shapes, but not every OpenAI parameter is carried. Some are rejected with 400 `unsupported_parameter` and any parameter not declared in this spec is accepted and ignored. The full table is at https://deeprelay.ai/docs/api/inference#openai-compatibility.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@deeprelay.ai

package/dist/esm/apis/MetaApi.js

@@ -2,7 +2,7 @@
 /* eslint-disable */
 /**
  * deeprelay Public Developer API
- * Programmatic API for deeprelay. Authenticate with API keys minted from the dashboard. See https://deeprelay.ai/docs for details.
+ * Programmatic API for deeprelay. Authenticate with API keys minted from the dashboard. See https://deeprelay.ai/docs for details.  Keys minted from the dashboard or `deeprelay login` belong to the Production server, https://api.deeprelay.ai/v1. The Demo server is an internal staging environment with its own key store.  Versioning: `/v1` is the API version. `info.version` is the revision of this `/v1` document, not a separate API.  OpenAI compatibility: chat completions follow the OpenAI request and response shapes, but not every OpenAI parameter is carried. Some are rejected with 400 `unsupported_parameter` and any parameter not declared in this spec is accepted and ignored. The full table is at https://deeprelay.ai/docs/api/inference#openai-compatibility.
  *
  * The version of the OpenAPI document: 1.0.0
  * Contact: support@deeprelay.ai