JWT for the Upload API Authorization: Bearer <token> scheme. Accepts a
plain token, a resolver function, or a provider. A resolver is called before
every request, so long-running uploads (e.g. multipart) can supply a fresh
token mid-flight.
This client never stores a token between calls. Rather than fetching one per
request, pass an AuthTokenCache from @uploadcare/signed-uploads/client,
which holds the token and replaces it shortly before it expires:
Passing tokens.getToken still works, and the cache still replaces the token
on expiry. What the provider form adds is recovery from a token the server
refuses: this client drops the cached one and retries once, which is what
saves an upload whose token ran out of operations.
Mint tokens on your server with generateAuthToken from
@uploadcare/signed-uploads — it needs the project secret key.
Takes precedence over legacy secureSignature / secureExpire: when both
are provided, only the Authorization header is sent.
JWT for the Upload API
Authorization: Bearer <token>scheme. Accepts a plain token, a resolver function, or a provider. A resolver is called before every request, so long-running uploads (e.g. multipart) can supply a fresh token mid-flight.This client never stores a token between calls. Rather than fetching one per request, pass an
AuthTokenCachefrom@uploadcare/signed-uploads/client, which holds the token and replaces it shortly before it expires:Passing
tokens.getTokenstill works, and the cache still replaces the token on expiry. What the provider form adds is recovery from a token the server refuses: this client drops the cached one and retries once, which is what saves an upload whose token ran out of operations.Mint tokens on your server with
generateAuthTokenfrom@uploadcare/signed-uploads— it needs the project secret key.Takes precedence over legacy
secureSignature/secureExpire: when both are provided, only the Authorization header is sent.