Which signing algorithm should I choose?

Prefer asymmetric algorithms such as RS256 or ES256 so tokens can be verified without sharing private keys; use HS256 only when both issuer and verifier can securely manage a shared secret.

How often should I rotate signing keys?

Rotate keys on a schedule that balances operational effort and risk. Typical rotation cadences are 90–365 days; publish the new key in JWKS before retiring the old key and monitor verifiers for compatibility.

How can I revoke a JWT before expiry?

Because JWTs are stateless, implement short lifetimes and a token blacklist or reference revocation list on the server side; alternatively issue opaque reference tokens backed by server-side sessions for immediate revocation.

What about clock skew in validation?

Allow a small clock skew (e.g., 60–120 seconds) when comparing iat and exp, but avoid large skew windows that weaken expiry guarantees; synchronize servers with NTP.

Where should secrets and private keys be stored?

Store private keys and secrets in a secure key management system or hardware security module (HSM); never commit keys to source control or expose them in client-side code.

Are JWTs legally binding for signatures?

JWTs are a technical authentication mechanism. Legal enforceability of an electronic signature depends on laws such as the ESIGN Act (15 U.S.C. ch. 96) and UETA; consult legal counsel for signature-specific requirements.

Electronic Signature
Templates
Miscellaneous
API JWT Token Template

API JWT Token Template

This template is fully customizable. Edit the text, fill out the fields, and send it for signature. Give it a try!

API JWT Token Template

This API JSON Web Token (JWT) Issuance and Use Agreement (the "Agreement") is entered into as of by and between Service Provider: and Client: .

RECITALS

WHEREAS, Provider operates and maintains the API services and authentication infrastructure and is authorized to issue JSON Web Tokens (JWTs) for access to designated API endpoints; and

WHEREAS, Client requires tokens for programmatic access to Provider's API in accordance with the terms and security controls set forth in this Agreement; and

WHEREAS, the parties intend to set forth the scope of token issuance, usage limits, security responsibilities, payment and termination provisions governing issuance and use of JWTs.

SCOPE OF WORK

Scope Description

Provider will issue JWTs to Client for authentication and authorization to the extent described in the Scope Description. Provider's obligations are limited to generating, signing, and distributing tokens in accordance with the Token Specifications below and maintaining reasonably secure key management and issuance logs.

TOKEN SPECIFICATIONS

Token Type Signing Algorithm Key Identifier (kid)

Token Lifetime (days):

Rotation Period (days):

Maximum Concurrent Tokens:

Standard Claims & Custom Claims

PAYMENT TERMS

Fee Amount Payment Schedule

Payment Due (days):

Late Fee (% per month):

All fees are exclusive of taxes. Unless otherwise specified, Client is responsible for all applicable taxes. Provider may suspend token issuance or revoke active tokens for nonpayment after thirty (30) days' written notice and an opportunity to cure.

TERM AND TERMINATION

Start Date:

End Date:

Notice Period (days):

Termination for Cause

Upon termination or expiration, Provider will revoke or expire issued tokens in accordance with its revocation procedures and the parties' instructions. Termination will not relieve Client of obligations to pay accrued fees through the effective date of termination.

CONFIDENTIALITY

Each party acknowledges that in the performance of this Agreement it may receive Confidential Information of the other party. Confidential Information includes, without limitation, private keys, token signing keys, internal endpoints, audit logs, and non-public technical specifications.

Confidential Information Description

By checking, the undersigned acknowledge and agree to maintain Confidential Information in strict confidence and to use it only as necessary to perform under this Agreement.

Confidentiality obligations shall survive termination for a period of years, except where a longer statutory period applies.

SECURITY, REVOCATION & AUDIT

Provider will maintain commercially reasonable security measures for issuance and storage of signing keys, including periodic rotation as specified above. Provider shall provide revocation mechanisms sufficient to invalidate tokens prior to natural expiration upon reasonable request. Client shall protect any tokens and credentials and shall promptly notify Provider of any suspected compromise.

Audit and Reporting

LIMITATIONS OF LIABILITY & INDEMNIFICATION

Liability Cap Indemnification

GOVERNING LAW

This Agreement will be governed by and construed in accordance with the laws of without regard to conflict of law principles.

ENTIRE AGREEMENT

This Agreement, including all Schedules and Exhibits expressly incorporated in writing, constitutes the entire agreement between the parties with respect to the subject matter hereof and supersedes all prior and contemporaneous agreements and understandings, whether written or oral. Any amendment to this Agreement must be in writing and signed by authorized representatives of both parties.

MISCELLANEOUS

Notices

Service Provider

Party Label:

By:

Date:

Client

Party Label:

By:

Date:

What the API JWT Token Template Is and When to Use It

The API JWT Token Template is a reusable specification and set of example claims, headers, and signing instructions for issuing JSON Web Tokens (JWTs) for API authentication and authorization. It standardizes required claims (iss, sub, aud, exp, iat), recommended lifetimes, recommended signing algorithms, and key rotation guidance so teams can issue, validate, and revoke tokens consistently across services and clients.

Why standardize a JWT token template for your APIs

A consistent JWT template reduces implementation errors, improves interoperability across microservices and third-party clients, and simplifies audits. Standardization supports secure practices like short token lifetimes, explicit audiences, and documented key rotation, which together lower the risk of credential leakage and unauthorized access.

Step-by-step: create and deploy a JWT using the template

Follow these ordered steps to produce a valid JWT from the template and ensure reliable validation by downstream services.

01

Prepare claims: Populate iss, sub, aud, iat, exp and any custom claims required by APIs.
02

Choose algorithm: Prefer RS256 or ES256 for asymmetric signing; use HS256 only when symmetric secrets are managed securely.
03

Sign token: Apply the configured private key or secret and include kid header for key lookup.
04

Test & rotate: Validate signature, claims, and expiry; schedule key rotation and verify compatibility before revoking keys.

Core parts of a professional API JWT Token Template

A complete template documents cryptographic choices, required claims, examples, validation rules, and operational procedures so developers, security teams, and auditors share the same expectations.

Header

Defines the signing algorithm (alg) and key identifier (kid); include examples for RS256 and HS256 and guidance on kid use.

Registered claims

Document required standard claims (iss, sub, aud, exp, iat) with formats, types, and validation rules for each claim.

Custom claims

List permitted application-specific claims and acceptable values; avoid overloading tokens with excessive data to reduce attack surface.

Signing guidance

Specify preferred algorithms, key sizes, how to sign, and how to expose verification keys (JWKS endpoint or key distribution).

Validation rules

State exact checks: signature verification, exp/i at comparisons, aud/iss equality checks, and acceptable clock skew.

Operational notes

Include rotation schedules, revocation process, logging/audit requirements, and emergency key-compromise procedures.

Required security and identification fields at a glance

Algorithm: RS256 preferred

Key ID (kid): Matches JWKS entry

Expiration (exp): Epoch seconds

Audience (aud): Exact resource ID

Issuer (iss): Service URI

Signature: Cryptographic verification

Who typically uses this JWT template

The template bridges development and security by making expectations explicit and replicable across production, staging, and third-party integrations.

Backend developers building microservices using token-based auth who require consistent claim expectations.
API platform teams issuing access tokens to third-party clients and mobile applications.
Security and compliance teams auditing token lifecycles and key management practices across services.

Real integration examples using standardized tokens

These brief examples show how teams apply an API JWT Token Template to real integrations and operational workflows.

Kodi-Marie Evans, Xerox

Xerox integrated templated tokens into their NetSuite workflows to standardize authentication across services.

The integration relied on formal key rotation and a JWKS endpoint.
By documenting claims and rotation procedures, Xerox reduced ambiguity for integrators and improved auditability while keeping token lifetimes short for security.

John Butler, Fertility Centers of Illinois

The team used a consistent JWT template to secure API calls from patient portals and backend systems.

The API has been great for programmatic signing and verification.
Consistent templates and a public JWKS simplified verifier configuration and reduced token-related support requests.

Where to send and how tokens are consumed

Tokens follow a standard flow from issuer to consumer; document where tokens are accepted and the validation steps each resource enforces.

Generate Token: Issuer signs claims and returns a compact JWT string.
Send to API: Include as Authorization: Bearer <token> in HTTPS requests.
Validate Token: Resource verifies signature, exp, aud, iss and iat.
Respond: API enforces scopes/claims, then returns authorized data.

Configure your token workflow: recommended settings

Set these configuration values in your authorization server and document them in the template to ensure consistent behavior across environments.

Field	Recommended value
Default token lifetime	300 seconds (5 minutes) for access tokens
Refresh policy	Issue short-lived access tokens with refresh tokens
Clock skew allowance	Allow up to 120 seconds drift
JWKS endpoint	HTTPS endpoint exposing public keys

How tokens are distributed and supported across platforms

Also list supported integrations and formats (OpenAPI examples, Postman collections, JWKS) and document any platform-specific constraints such as CORS, cookie policies, or SDK version compatibility.

HTTP Header: Authorization: Bearer preferred for APIs
Cookie Storage: Use secure, SameSite cookies for browser session tokens
SDKs and Integrations: Support server SDKs, mobile SDKs, and a JS client library

Files and resources to include with the template

Attach machine-readable and human-readable artifacts so implementers can quickly test and adopt the template with correct tooling and examples.

OpenAPI examples

Provide request/response examples showing Authorization header usage and sample payloads; include securitySchemes definitions for automated client generation.

Postman collection

Include ready-to-run requests for token issuance and protected endpoints with environment variables for issuer, client_id, and JWKS URL.

JWKS endpoint specification

Document the JWKS structure, key rotation cadence, and kid mapping so verifiers can fetch and cache keys safely.

Revocation guidance

Provide an approach for token revocation or short-lived tokens combined with server-side session invalidation for high-risk scenarios.

Common mistakes teams make when preparing JWT templates

Using long expiration periods for access tokens which increases exposure if a token is stolen and complicates revocation.
Storing secrets or private keys in source code or client-side storage such as localStorage without adequate protection or rotation plans.
Failing to validate audience or issuer values, allowing tokens intended for other services to be accepted by mistake.
Not publishing a JWKS endpoint or using inconsistent kid values, causing verifiers to fail signature lookup and reject valid tokens.

Security risks and operational consequences of a faulty template

Exposed secret: Credential compromise

Excessive lifetime: Prolonged unauthorized access

Missing aud check: Token misuse across services

No revocation: Unable to invalidate tokens

Weak algorithm: Susceptible to signature attacks

Improper logging: Insufficient audit trail

Suggested timing and lifecycle controls for tokens

Establish clear schedules for expiry, rotation, and audits so tokens are short-lived and keys are rotated before expiry to avoid service disruption.

Token expiry window:

Access tokens: 5–60 minutes depending on sensitivity

Refresh token policy:

Rotate refresh tokens every 30–90 days and bind to client/device

Key rotation cadence:

Rotate signing keys every 90–365 days based on risk profile

Audit schedule:

Review token issuance logs and JWKS usage monthly

Revocation SLA:

Document expected revocation propagation time and test it quarterly

eSignature vendor pricing and capability snapshot for API token workflows

Compare common eSignature providers for API-driven signing and token-based integrations; signNow is shown first per platform comparison conventions.

	signNow	DocuSign	Adobe Sign	PandaDoc	HelloSign
Starting Price	$8/user/mo	$15/user/mo	$14/user/mo	$19/user/mo	$15/user/mo
Free Trial	7-day free trial	Varied by plan	Varied by plan	Varied by plan	Varied by plan
Bulk Send	Yes	Yes	Yes	Yes	Yes
Audit Trail	Yes	Yes	Yes	Yes	Yes
HIPAA Compliant	Yes	Yes	Yes	No	No

FAQs and troubleshooting for the API JWT Token Template

Answers to common questions about algorithms, key rotation, revocation, and validation to reduce implementation errors and support operational readiness.

Need help? Contact support

Which signing algorithm should I choose?
Prefer asymmetric algorithms such as RS256 or ES256 so tokens can be verified without sharing private keys; use HS256 only when both issuer and verifier can securely manage a shared secret.
How often should I rotate signing keys?
Rotate keys on a schedule that balances operational effort and risk. Typical rotation cadences are 90–365 days; publish the new key in JWKS before retiring the old key and monitor verifiers for compatibility.
How can I revoke a JWT before expiry?
Because JWTs are stateless, implement short lifetimes and a token blacklist or reference revocation list on the server side; alternatively issue opaque reference tokens backed by server-side sessions for immediate revocation.
What about clock skew in validation?
Allow a small clock skew (e.g., 60–120 seconds) when comparing iat and exp, but avoid large skew windows that weaken expiry guarantees; synchronize servers with NTP.
Where should secrets and private keys be stored?
Store private keys and secrets in a secure key management system or hardware security module (HSM); never commit keys to source control or expose them in client-side code.
Are JWTs legally binding for signatures?
JWTs are a technical authentication mechanism. Legal enforceability of an electronic signature depends on laws such as the ESIGN Act (15 U.S.C. ch. 96) and UETA; consult legal counsel for signature-specific requirements.

be ready to get more

Join over 28 million airSlate SignNow users

Sign Now