AutoCertify API

What AutoCertify is

AutoCertify provisions publicly trusted domain-validation certificates through Cloudflare for SaaS Custom Hostnames. Cloudflare manages the certificate and private key at its edge. AutoCertify reports active only after Cloudflare reports both the custom hostname and its SSL certificate as active.

Your website also needs the appropriate traffic routing and origin configuration for the AutoCertify service. The validation records prove domain control; they do not change where visitors connect. Confirm the routing setup for your hostname before changing its website DNS.

What you can build

• Provision managed certificates. Add hostnames to your workspace and publish the records needed to validate them.
• Automate your domain workflow. Create domains in bulk, organize them with tags, and request provider status checks from your own application.
• Receive issuance events. Register signed webhooks and combine them with explicit status refreshes to keep your application informed.

The core model: delegation and ownership

A certificate authority must confirm you control a domain before it issues a certificate — this is Domain Control Validation (DCV). AutoCertify uses delegated DCV: a CNAME points _acme-challenge.<domain> at the returned Cloudflare DCV target. A separate TXT record at _autocertify-verify.<domain> binds that domain to your AutoCertify workspace. Both records must match your domain response before verification succeeds.

1. Create a domain and read validation.delegation and validation.ownership.
2. Add both records at the authoritative DNS provider and keep them published.
3. Verify the records to start or check issuance.
4. Refresh certificate status, confirm the website’s HTTPS connection, and monitor the domain.

Base URL

All requests go to https://api.autocertify.net. Authenticated resources live under the /v1/ prefix. Send and receive application/json.

Authentication

Authenticate every request with a bearer token: Authorization: Bearer <token>. Two kinds of token are accepted:

• API keys — ac_live_… keys for server-to-server automation. Create and rotate them in the dashboard; the full key is shown only once at creation.
• Auth0 session ID tokens — the verified id_token returned in the token field by AutoCertify’s sign-in exchange. Verification checks the issuer, signature, expiry and configured client audience.

Creating or changing API keys, webhook credentials, and team membership, as well as billing checkout, requires an owner or admin session. API keys cannot perform these actions. Domain, client and certificate changes and verification-link access require an owner, admin or operator session, or an API key with the required scopes; a read_only session cannot perform those actions. Keep automation keys in server-side secret storage. Public endpoints, including sign-up and verification-link views, are identified in the reference. The quickstart shows how to set the token and domain ID used below.

curl --fail-with-body https://api.autocertify.net/v1/domains/$AUTOCERTIFY_DOMAIN_ID \
  -H "Authorization: Bearer $AUTOCERTIFY_TOKEN"

Responses & errors

A successful call returns the requested resource (or a small result object) directly, with an appropriate 2xx status — for example, creating a domain returns 201 with the Domain. Errors return a single, predictable envelope:

{
  "status": 400,
  "code": "validation_error",
  "message": "Validation failed.",
  "details": {
    "formErrors": [],
    "fieldErrors": {
      "apex": ["Please enter a valid domain, like example.com"]
    }
  }
}

status mirrors the HTTP status, code is a stable machine-readable string, message is human-readable, and details is present on some errors. Validation errors use details.formErrors and details.fieldErrors. Optional response fields are omitted when unavailable; clients should not assume every timestamp or certificate summary is present.

Rate limits

The default limits below apply per client IP in a fixed 15-minute window. Deployments can configure these values. Check the RateLimit and RateLimit-Policy headers; a 429 rate_limited response also includes Retry-After.

• /v1/* — 600 requests across all API routes before authentication.
• /v1/auth/* — 20 requests per window, within the shared API limit.
• /v1/public/signup — a separate 20-request bucket.
• /v1/public/verification-links/* — 60 requests per window.
• /v1/verification-links/* — a separate 60-request bucket.
• /v1/site-scan/* — 120 requests per window.

Next steps

Pick where to go from here: