From endpoint to live HTTPS
with visible status

Start by creating an account at sslforsaas.io/register. Billing details are collected only when you select a plan and continue to Stripe-hosted checkout. Once registered, you'll land in the app where you can create your first workspace and project.

Once you're in, your dashboard gives you access to your project settings, domain list, certificate status, webhook configuration, and account settings. Generate project API keys only when you need server-to-server automation.

Your application endpoint is where SSLforSaaS will forward customer traffic after the SSL certificate is applied. This is the hostname of your SaaS application — the server or load balancer that handles your customers' requests.

For example, if your customers visit app.customerdomain.com, SSLforSaaS will terminate SSL and proxy all traffic to your endpoint, such as app.yourplatform.com.

Navigate to Settings → Application Endpoint in your dashboard and enter your hostname:

SSLforSaaS will perform a quick connectivity check to verify your endpoint is reachable. Once verified, a green checkmark appears and you're ready for the next step.

• Load balancer or hostname

  Use a hostname like app.yourplatform.com pointing to your load balancer or primary server.
• Multiple regions

  If your infrastructure spans regions, use a GeoDNS-aware hostname. SSLforSaaS proxies to whatever your DNS resolves to.
• HTTPS endpoint

  If your endpoint is already serving HTTPS, SSLforSaaS will connect to it securely and maintain end-to-end encryption.

After project provisioning completes, Project Settings shows a project-specific CNAME target such as <project-id>.sslforsaas.io. This is the authoritative target to share with customers.

Do not substitute a shared sample hostname or IP address. Copy the exact value shown for the current project:

Open Project Settings → Network to copy the target and review the customer handoff instructions:

Once your setup is complete, you need to tell your customers how to point their custom domain to your platform. This involves adding a simple DNS record in their registrar. Provide them with clear instructions — the exact record depends on whether they're using an apex (root) domain or a subdomain.

For subdomains (e.g. app.customerdomain.com), your customers add a CNAME record:

For apex (root) domains (e.g. customerdomain.com), use a DNS provider that supports ALIAS, ANAME, or CNAME flattening to the same project target:

After the domain is added and DNS resolves to the assigned target, provider-backed certificate provisioning begins. Timing depends on DNS and provider validation; wait for the app to report the domain as active before cutover.

While certificates are issued automatically after customer DNS points at SSLforSaaS, project owners can also queue domains through the project-scoped REST API when server-to-server automation is enabled for the project.

# Queue a customer domain under a project
curl -X POST https://api.sslforsaas.io/workspaces/{workspaceId}/projects/{projectId}/domains \
  -H "Authorization: Bearer {PROJECT_API_KEY}" \
  -H "Content-Type: application/json" \
  -d '{"domain_name":"app.customerdomain.com"}'

# Response: 202 Accepted
{
  "message": "Domain creation accepted and queued for asynchronous provisioning.",
  "domain_id": "65f000000000000000000001",
  "operation_id": "8b39f8a3-6f1b-4e85-8d4e-a8711a9e52d1",
  "provisioning": {
    "state": "queued",
    "certificate_status": "pending"
  }
}

Configure project webhooks in the dashboard to receive signed outbound events for supported workspace and user event types.

{
  "event_type": "workspace.domain_enabled",
  "scope": "workspace",
  "severity": "info",
  "workspace_id": "65f000000000000000000000",
  "project_id": "65f000000000000000000111",
  "payload": {
    "domain_id": "65f000000000000000000001",
    "domain_name": "app.customerdomain.com",
    "ssl_status": "active"
  },
  "occurred_at": "2026-04-10T09:41:30Z"
}

Once your core setup is running, SSLforSaaS offers several advanced options to fine-tune how traffic is handled, secured, and routed. These are optional but recommended for production deployments.

• Monitor certificate lifecycle

  Use the domain status shown in the app to track DNS validation, certificate issuance, and activation. Certificate-authority selection is provider-managed.
• Follow provider-specific DNS guidance

  Use the exact target and validation instructions shown for the domain. If another Cloudflare account proxies the source record, provider restrictions may require DNS-only validation or a different handoff.
• Custom request headers

  Attach custom HTTP headers to every proxied request — for example, pass a X-Customer-Domain header to your application so it knows which tenant is being served.
• URL rewriting

  Configure path rewrites when proxying to your endpoint. For example, map all traffic from /app/* to a different backend path on your application server.
• Project webhook notifications

  Configure project webhooks for supported lifecycle events and verify delivery from Project Settings. The current product does not expose self-service certificate upload.