/**
 * January AI - Nutrition Intelligence APIs
 * Build food and metabolic intelligence into your product — one API for understanding what people eat and how food may affect them.  **Clinical-grade precision, consumer-grade experiences.** January builds the infrastructure underneath the product: turning messy health and nutrition data into reliable intelligence, so your team spends its time on the experience instead of the foundation.  **Security & compliance** — **SOC 2 Type II** · **HIPAA-aligned practices** · **BAA** and **Zero Data Retention (ZDR)** available  **What you can build** - **Scan food** — photo and text food recognition: detect foods and nutrition, then correct results conversationally - **Search the food database** — by name or barcode — and get healthier alternatives for any food - **Log food, water and weight** — per-user diaries with day-range queries - **Predict glucose response** to any meal — no sensor required  **Getting started** 1. Create an API key in the [Developer Dashboard](https://dashboard.january.ai) — the full key is shown once, at creation. 2. Send it as `Authorization: Bearer sk-…` — click **Authorize** here to make every example below a live request. 3. On the endpoints that read or write an end user\'s logs, say whose with the `January-End-User-ID` header — each one documents it. No other endpoint takes it: everything else either asks the shared food database a question or works on the body you send, and neither depends on who the food is for.  **Calling from a mobile app** — your `sk-` key must never ship inside an app. Instead, exchange it on your backend for a *client token*: a credential that lasts up to two hours, acts as exactly one of your end users, and carries only the scopes you grant it (see the **authentication** section). Your app then calls these endpoints directly, with no proxy of your own in the request path. Both credentials travel in the same `Authorization: Bearer` header, and every endpoint below opens by saying which it accepts — **API key or client token**, or **API key only**.  **Support** — [support@january.ai](mailto:support@january.ai) · [Discord community](https://discord.gg/cYQeh3UnC) · [docs.january.ai](https://docs.january.ai)
 *
 * The version of the OpenAPI document: 1.2
 * Contact: support@january.ai
 *
 * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech).
 * https://openapi-generator.tech
 * Do not edit the class manually.
 */
import * as runtime from '../runtime.js';
import { type ClientToken } from '../models/ClientToken.js';
import { type ClientTokenRevocationResult } from '../models/ClientTokenRevocationResult.js';
import { type CreateClientTokenBody } from '../models/CreateClientTokenBody.js';
import { type RevokeClientTokensBody } from '../models/RevokeClientTokensBody.js';
export interface CreateClientTokenRequest {
    createClientTokenBody: CreateClientTokenBody;
}
export interface RevokeClientTokensRequest {
    revokeClientTokensBody: RevokeClientTokensBody;
}
/**
 *
 */
export declare class AuthenticationApi extends runtime.BaseAPI {
    /**
     * Creates request options for createClientToken without sending the request
     */
    createClientTokenRequestOpts(requestParameters: CreateClientTokenRequest): Promise<runtime.RequestOpts>;
    /**
     * **API key only.**  Exchanges your partner API key for a short-lived token bound to one of your end users, so your mobile app can call the v1.2 API directly instead of through a proxy that holds your key.  **This endpoint requires your API key (`sk-…`), so always call it from your backend** — behind whatever login already protects your own APIs. Never ship your API key in a mobile app in order to call this from the device: that puts a credential for your whole account in every copy of your app, which is the problem client tokens exist to solve.  The end user is identified by `end_user_id` in the body, not the `January-End-User-ID` header: the token is bound to it, and requests made with the token act only on that user, whatever headers they carry.  Tokens last 300–7200 seconds and the raw value is returned exactly once — it is stored only as a hash, so it can never be retrieved again. Relay it to the device and let the device refresh when it expires: a `401` with code `token_expired` is the signal to mint a new one and retry the original request once.
     * Mint a client token
     */
    createClientTokenRaw(requestParameters: CreateClientTokenRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<ClientToken>>;
    /**
     * **API key only.**  Exchanges your partner API key for a short-lived token bound to one of your end users, so your mobile app can call the v1.2 API directly instead of through a proxy that holds your key.  **This endpoint requires your API key (`sk-…`), so always call it from your backend** — behind whatever login already protects your own APIs. Never ship your API key in a mobile app in order to call this from the device: that puts a credential for your whole account in every copy of your app, which is the problem client tokens exist to solve.  The end user is identified by `end_user_id` in the body, not the `January-End-User-ID` header: the token is bound to it, and requests made with the token act only on that user, whatever headers they carry.  Tokens last 300–7200 seconds and the raw value is returned exactly once — it is stored only as a hash, so it can never be retrieved again. Relay it to the device and let the device refresh when it expires: a `401` with code `token_expired` is the signal to mint a new one and retry the original request once.
     * Mint a client token
     */
    createClientToken(requestParameters: CreateClientTokenRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<ClientToken>;
    /**
     * Creates request options for revokeClientTokens without sending the request
     */
    revokeClientTokensRequestOpts(requestParameters: RevokeClientTokensRequest): Promise<runtime.RequestOpts>;
    /**
     * **API key only.**  Revokes every outstanding client token for one end user. Safe to call repeatedly: it reports how many tokens it actually stopped, so an immediate second call reports 0.  **This endpoint requires your API key (`sk-…`), so always call it from your backend.** A client token cannot revoke anything, its own included.  Revocation takes effect within 60 seconds, the authentication cache window. For an immediate cut-off, stop trusting the user in your own app as well — and note that a token minted in the same instant as the revoke may survive it, bounded by its own expiry.  If some tokens cannot be revoked, the call answers `503` with code `client_token_revocation_incomplete`, naming how many of them succeeded rather than reporting a smaller count as though it were the whole story — **retry until it succeeds**, which only picks up the remainder.  One call stops at most 500 tokens so it cannot time out, so **repeat the call until `revoked_count` is 0** if a user is somehow holding more than that (which means your app is minting per request rather than per session).
     * Revoke an end user’s client tokens
     */
    revokeClientTokensRaw(requestParameters: RevokeClientTokensRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<runtime.ApiResponse<ClientTokenRevocationResult>>;
    /**
     * **API key only.**  Revokes every outstanding client token for one end user. Safe to call repeatedly: it reports how many tokens it actually stopped, so an immediate second call reports 0.  **This endpoint requires your API key (`sk-…`), so always call it from your backend.** A client token cannot revoke anything, its own included.  Revocation takes effect within 60 seconds, the authentication cache window. For an immediate cut-off, stop trusting the user in your own app as well — and note that a token minted in the same instant as the revoke may survive it, bounded by its own expiry.  If some tokens cannot be revoked, the call answers `503` with code `client_token_revocation_incomplete`, naming how many of them succeeded rather than reporting a smaller count as though it were the whole story — **retry until it succeeds**, which only picks up the remainder.  One call stops at most 500 tokens so it cannot time out, so **repeat the call until `revoked_count` is 0** if a user is somehow holding more than that (which means your app is minting per request rather than per session).
     * Revoke an end user’s client tokens
     */
    revokeClientTokens(requestParameters: RevokeClientTokensRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise<ClientTokenRevocationResult>;
}
//# sourceMappingURL=AuthenticationApi.d.ts.map