SSL Cert Info API
Fetches the TLS certificate a host presents: issuer, subject, SAN list, validity window, days to expiry and the full chain.
Reading a live certificate needs a TLS handshake against the host, which an agent may be unable to make; the days-to-expiry and chain view are what you monitor across a fleet of domains.
01Request
HTTP request
POST /v1/ssl-cert-info
content-type: application/json
payment-signature: <base64 x402 payload>
{
"domain": "example.com"
}Without the payment-signature header the call answers 402 with the payment requirements, including this endpoint's price and its max_timeout_seconds, so the deadline is known before anything is paid. The payment is verified before the handler runs and settled only after it succeeds, so a call refused by the gate, or one that fails inside the handler, is never settled. The single case we cannot state for you is a settlement call that fails without answering: the error message says so when that is what happened.
02Call it from code
JavaScript
// ssl-cert-info: $0.002 per call, paid in USD Coin on eip155:8453 via x402
// Install: npm install @x402/fetch@2 @x402/evm@2 viem@2
// Save as client.mjs (ES module, Node 18+), export EVM_PRIVATE_KEY with the paying wallet's key in your shell, then run: node client.mjs
// The wrapper reads the 402 (payment-required), signs and retries with payment-signature.
import { wrapFetchWithPayment, x402Client, decodePaymentResponseHeader } from '@x402/fetch'
import { ExactEvmScheme } from '@x402/evm/exact/client'
import { privateKeyToAccount } from 'viem/accounts'
const account = privateKeyToAccount(process.env.EVM_PRIVATE_KEY)
const client = new x402Client().register('eip155:8453', new ExactEvmScheme(account))
const fetchWithPayment = wrapFetchWithPayment(fetch, client)
const body = {
"domain": "example.com"
}
const res = await fetchWithPayment('https://grist.tools/v1/ssl-cert-info', {
method: 'POST',
headers: { 'content-type': 'application/json' },
body: JSON.stringify(body),
})
console.log(res.status, await res.json())
const settle = res.headers.get('payment-response')
if (settle) console.log(decodePaymentResponseHeader(settle).transaction)Python
# ssl-cert-info: $0.002 per call, paid in USD Coin on eip155:8453 via x402
# Install: pip install "x402[requests,evm]>=2.24,<3"
# The session reads the 402 (payment-required), signs and retries with payment-signature.
import os
from eth_account import Account
from x402 import x402ClientSync
from x402.http import decode_payment_response_header
from x402.http.clients.requests import x402_requests
from x402.mechanisms.evm.exact import register_exact_evm_client
from x402.mechanisms.evm.signers import EthAccountSigner
account = Account.from_key(os.environ["EVM_PRIVATE_KEY"])
client = x402ClientSync()
register_exact_evm_client(client, EthAccountSigner(account), networks="eip155:8453")
session = x402_requests(client)
payload = {
"domain": "example.com"
}
res = session.post("https://grist.tools/v1/ssl-cert-info", json=payload)
print(res.status_code, res.json())
settle = res.headers.get("payment-response")
if settle:
print(decode_payment_response_header(settle).transaction)curl
# ssl-cert-info: $0.002 per call, paid in USD Coin on eip155:8453 via x402
# 1. Unpaid call: HTTP 402, the requirements in the payment-required header (base64 JSON) and in the body.
curl -i -X POST 'https://grist.tools/v1/ssl-cert-info' -H 'content-type: application/json' -d '{"domain":"example.com"}'
# 2. Same call with the signed payment (an EIP-3009 authorization, EIP-712 signed: it cannot be
# typed by hand). x-payment is accepted as the v1 alternative. HTTP 200 carries payment-response.
curl -i -X POST 'https://grist.tools/v1/ssl-cert-info' -H 'content-type: application/json' -H 'payment-signature: <base64 x402 payload>' -d '{"domain":"example.com"}'03Response
HTTP response
200 OK
payment-response: <base64 settlement receipt>
{
"host": "example.com",
"port": 443,
"issuer": "CN=R3, O=Let's Encrypt, C=US",
"subject": "CN=example.com, O=Example Inc, C=US",
"san": [
"example.com",
"www.example.com"
],
"valid_from": "2026-08-01T00:00:00.000Z",
"valid_to": "2026-10-30T23:59:59.000Z",
"days_to_expiry": 65,
"self_signed": false,
"chain": [
{
"issuer": "CN=R3, O=Let's Encrypt, C=US",
"subject": "CN=example.com, O=Example Inc, C=US",
"valid_from": "2026-08-01T00:00:00.000Z",
"valid_to": "2026-10-30T23:59:59.000Z"
},
{
"issuer": "CN=ISRG Root X1, O=Internet Security Research Group, C=US",
"subject": "CN=R3, O=Let's Encrypt, C=US",
"valid_from": "2020-09-04T00:00:00.000Z",
"valid_to": "2025-09-15T16:00:00.000Z"
}
],
"queried_at": "2026-08-26T18:00:00.000Z"
}This example is illustrative: it shows the exact shape the handler returns, but it was not produced by a reproducible call, because the real answer depends on live network data that changes over time.
04Input schema
The same schema the handler validates against, published from the same source. Also served, free, at/v1/ssl-cert-info/schema.
JSON Schema
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"properties": {
"domain": {
"description": "Public fully qualified domain name to connect to and send as SNI. Give exactly one of domain or url.",
"type": "string",
"minLength": 1
},
"url": {
"description": "An http(s) URL whose host is probed; an explicit port in the URL overrides the port field, and the path is ignored. Give exactly one of domain or url.",
"type": "string",
"minLength": 1
},
"port": {
"default": 443,
"description": "TLS port for the handshake, one of 443, 465, 636, 990, 993, 995, 8443; defaults to 443.",
"type": "integer",
"minimum": -9007199254740991,
"maximum": 9007199254740991
}
},
"additionalProperties": false
}05Errors
| Code | HTTP | When |
|---|---|---|
| invalid_input | 400 | The body does not match the schema on this page. Nothing is charged. |
| blocked_target | 403 | The destination is refused by the network guard: a disallowed address, or, for HTTP requests, a scheme other than http/https, a port other than 80/443, or credentials in the URL. |
| unreachable_target | 424 | The destination you named did not resolve or refused the connection. |
| upstream_timeout | 424 | The destination you named did not answer before the declared timeout for this endpoint expired. |
| internal | 500 | Our fault, and in almost every case nothing is charged. The exceptions come after the call has run and the settlement call was made: the message "The work was done but settlement could not be completed", and the messages starting with "Payment settlement returned". There, whether the payment moved is unknown to us as well. The payment moves at most once: its nonce is single-use and settlement is idempotent, so a retry with it is never charged twice. A retry is normally refused with a 402: replay_consumed, an expiry reason, or a reason saying the nonce was already used once the transfer is on-chain. Only if our server restarted before the transfer was final can a retry run the call again. Even then, the payment moves at most once. To see whether it was settled, read the EIP-3009 authorizationState of its nonce on-chain; to call again, sign a new payment. |
| rate_limited | 429 | Too many calls from the same payer, or too many calls towards the same destination domain. Nothing is charged. |
| concurrency_limit, registry_at_capacity, upstream_unavailable | 503 | We could not serve the call right now. Retryable: wait the number of seconds in the retry-after header, then repeat the call. concurrency_limit and registry_at_capacity mean we were at capacity: the call did not run. You can send the same payment again if its validBefore is still far enough away to cover another call. If it is not, the retry gets a 402 authorization_validity_too_short: sign a new payment. upstream_unavailable means our internal service failed or did not answer in time: the call may already have run and the payment may have been settled. A retry with the same payment can get a 402 whose error field says why. authorization_validity_too_short: too little time is left before validBefore to cover another call. This check comes before the replay check, so it does not tell whether the first payment was settled. replay_consumed (the payment was used and may have been settled) or replay_exhausted (too many attempts): sign a new payment. replay_in_flight: the first call is still running, so wait and do not pay again. invalid_exact_evm_nonce_already_used: the transfer is already on-chain, so this payment cannot move again. Sign a new payment. An authorization can be settled only once, since its nonce is single-use. To see whether it was settled, read the EIP-3009 authorizationState of its nonce on-chain. |
| misconfigured | 503 | The service is not configured to serve calls. The call did not run and nothing is charged. It needs a fix on our side, so there is no retry delay to wait for. |
06Questions
- What does a call to ssl-cert-info cost?
- $0.002 per call, paid via x402. An unpaid call answers 402 with the price and max_timeout_seconds, so both are known before anything is paid.
- How long can a call take?
- The handler has 10 s to answer. The 402 envelope declares max_timeout_seconds as 31: that timeout plus payment verification and settlement around it.
- What happens if the call fails?
- The payment is verified before the handler runs and settled only after it succeeds, so a call that fails inside the handler is not settled. The errors table in section 05 lists each code, its HTTP status and when it is raised.
- Where is the input schema?
- In section 04 on this page, and served free at /v1/ssl-cert-info/schema. It is the schema the handler validates against, also published in /openapi.json.