How authentication works
Platform-managed mTLS is the recommended Customer API authentication mode. Your client presents its active certificate on the dedicated TLS hostname to request a 10-minute access token. Authenticate with the certificate; do not create or send a JWT client assertion in this mode.
Every production data request then presents both the access token and the same active certificate. Wavac rejects bearer-only requests, a different certificate, forwarded certificate headers, and certificates presented to the ordinary API listener.
Plan token requests and certificate renewal together using the authentication limits. Reuse tokens rather than requesting one for every API call. Enrollment completion and renewal share an allowance; keep capacity available for renewal and recovery.
Request a token
curl --fail-with-body \
--cert ./client-fullchain.crt.pem \
--key ./client.key.pem \
--data-urlencode 'grant_type=client_credentials' \
--data-urlencode 'scope=customer.discovery.read' \
https://customer-api.wavac.io/api/customer/oauth/token
Do not include client_assertion or client_assertion_type in this mode. Keep
the returned access token only in memory and renew it before its 600-second
expiry.
Call the API
curl --fail-with-body \
--cert ./client-fullchain.crt.pem \
--key ./client.key.pem \
-H "Authorization: Bearer $WAVAC_ACCESS_TOKEN" \
-H 'Accept: application/json' \
https://customer-api.wavac.io/api/customer/v1/discovery
Renew the certificate
Generate a new RSA private key and CSR with the same API-supplied certificate subject. While presenting the current certificate, send the replacement CSR:
POST /api/customer/certificates/renew
Content-Type: application/json
{
"certificateSigningRequestPem": "-----BEGIN CERTIFICATE REQUEST-----\n...\n-----END CERTIFICATE REQUEST-----\n"
}
The replacement certificate is valid for exactly 24 hours. Keep its private key
and certificate in memory first. Use the candidate to request a token, prove the
token with HEAD /api/customer/v1/auth/session, and make one minimal discovery
request. Replace the stable certificate secret only after all three operations
succeed. The token cache key must include the certificate SHA-256 thumbprint, so
a token obtained with the predecessor cannot cross the handoff boundary.
The previous certificate remains accepted for the 10-minute access-token overlap, but only the replacement can initiate another renewal. This overlap lets already-running requests finish; it is not a reason to publish an unproven replacement. After overlap, the predecessor fails even if its original X.509 expiry is later.
If renewal fails near expiry, stop issuing new work and request a replacement enrollment handoff. Never reuse a CSR after an ambiguous response, disable TLS verification, or send private material to Wavac support.