SSL Reseller API: Automate SSL Sales from CSR to Certificate
Selling SSL certificates is more than firing off an order request. You still need to validate the CSR, walk the customer through domain validation, track order status until issuance, and hand over the certificate securely — plus handle reissues down the line. Domain Name API's SSL Reseller REST API lets you wire that entire lifecycle into your own website, customer portal, or internal ops system. You can test the full integration in the OT&E sandbox before a single request touches production.
Quick Answer
What it does: The SSL Reseller API automates CSR generation and validation, order initiation, domain-validation configuration, status tracking, certificate retrieval, and reissue requests.
Who it's for: Hosting companies, domain resellers, web agencies, MSPs, and any platform selling SSL under its own brand.
What you'll walk away with: A correctly sequenced order lifecycle, a completed OT&E test run, and the production-readiness checks — including private-key handling — needed before you go live.
Who Is the SSL Reseller API For?
- Hosting companies
- Domain resellers and registrar service providers
- Web design and software agencies
- MSPs and IT service providers
- SaaS teams building their own customer dashboards
- Platforms selling SSL products under their own brand
If you just need basic HTTPS on a single personal site, a free DV certificate is probably enough. The SSL Reseller API earns its keep once you're selling paid SSL products, juggling multiple validation levels, or managing certificate orders for many customers at once.
What Does an SSL API Integration Actually Get You?
Less manual work
Order creation, validation-method selection, status checks, and certificate delivery all run through one system instead of several disconnected screens.
A clearer customer experience
Instead of a single 'order created' message, you can surface real stages: domain validation pending, organization validation pending, certificate issued, or action required.
Fewer costly mistakes
CSR, domain, and order details can be checked before anything reaches the certificate authority — so a mismatched domain, malformed CSR, or missing validation detail gets caught early instead of bouncing back as a rejected order.
A controlled path to production
The OT&E sandbox lets you exercise the entire flow without touching production credentials or triggering a real CA process.
Live API vs. OT&E Sandbox
For a broader overview of how live and OT&E access work together, see the Domain Name API Test Platform Guide.
Where Do You Get API Credentials?
The REST API doesn't use your portal login email and password. Credentials live in the Integration Information section of the reseller panel:
- Live environment: Reseller ID and API Key
- OT&E environment: OT&E Reseller ID and OT&E API Key
Reseller panel: https://dm.apiname.com/ Don't mix live and test credentials — a mismatch between environment and key returns an authorization error. If you rely on IP whitelisting, register the fixed outbound IP of the server making the calls in the panel.
🔒 Security Note
Never store your API Key, CSR private key, or customer data in source code, client-side JavaScript, public repositories, or unmasked logs.
SSL Reseller API Endpoints
Required fields, data types, product codes, validation options, and response models can change; always confirm the current schema in Swagger rather than guessing field names or response shapes from the endpoint name.
The SSL Order Lifecycle
1. Define the product and scope
Choose single-domain, Wildcard, or Multi-Domain/SAN based on what the customer needs. DV, OV, and EV products have different validation requirements. Confirm the product code, term length, and supported features against the reseller panel and Swagger.
2. Generate or check the CSR
Use generate-csr if you need a new CSR, or check-csr to validate one the customer already has. Confirm the CSR format and that the Common Name and SAN entries match the order's scope. Check the Swagger schema to see whether the CSR-generation response includes a private key. If it does, store it in a secure key vault immediately.
3. Start the order
Call initialize to open the order and associate the returned order ID with your own order record. This step does not mean the certificate has been issued. Keep 'order created' and 'certificate ready' visually distinct in your UI.
4. Configure validation
If you're using email-based validation, call approvers to get valid options first. Then use configure to attach the CSR and the supported validation method, along with any required order details.
5. Track status
Poll check-status to monitor progress. Don't hammer the endpoint at very short intervals — use a sensible polling interval with backoff. Translate the raw status code into something the customer understands: 'DNS record pending', 'Approval email pending', or 'Certificate ready to download'.
6. Retrieve the certificate
Once the order reaches an issued state, call GET /api/v1/ssls/certificate. Confirm the exact shape of the certificate and chain fields in Swagger. Before delivery, verify domain coverage, validity dates, the certificate chain, and that the private key actually matches.
7. Reissue when needed
Use the reissue endpoint after a key change or another supported scenario. Confirm the new CSR requirements and product terms in Swagger and the reseller panel.
Recommended OT&E Test Plan
- Connect using your OT&E credentials.
- Test both valid and invalid CSR scenarios.
- Start a test order and store the order ID.
- Retrieve approver options.
- Configure a supported validation method.
- Surface each status transition correctly in your customer-facing UI.
- Test the certificate response and chain handling.
- Test the reissue scenario if your product supports it.
- Confirm the same order can't be created twice.
- Test unauthorized access, timeouts, and error responses.
- Verify your logs contain no API keys, private keys, or personal data.
Once your OT&E tests pass, switch only the base URL and the matching environment credentials to move to production.
Critical Controls for a Secure Integration
Prevent duplicate orders
If a network error occurs on initialize or reissue, don't immediately fire off a new order. Check whether the previous call actually succeeded first, and use a unique local order reference to make that check reliable.
Mask sensitive data
API keys, private keys, contact details, and validation data should never appear in full in logs.
Don't treat DV, OV, and EV as interchangeable
DV typically relies on domain control alone. OV and EV can require organization vetting, which takes longer — don't promise a fixed turnaround time across all three.
Common API Issues
Test Your First SSL Order Before It's Live
Run the full flow — CSR check through certificate delivery — in the OT&E sandbox. That's how you catch a mismatched domain, an incomplete validation step, or a duplicate-order bug before a real customer ever sees it.
Next step: open the OT&E Swagger docs and pull your test credentials.
Haven't picked a product yet? Browse the SSL Reseller lineup and current wholesale pricing.
Related Guides
- Domain Name API Test Platform Guide
- Reseller Hosting API & OT&E Sandbox Guide
- SSL Reseller Program
- Reseller panel
Frequently Asked Questions
Does OT&E issue a real certificate?
No. OT&E is strictly for testing — never treat sandbox resources as production output. Live orders require the production base URL and production credentials.
Do I have to generate the CSR through the API?
No. An existing CSR can be validated with check-csr, or you can generate a new one with generate-csr. Confirm the exact request and response structure in Swagger.
Which validation method is best?
There's no single best option — the right choice depends on the product, the issuing CA, and whether your customer has easy access to DNS, email, or their web server.
How long does issuance take?
It depends on the certificate type and validation path. DV is usually fastest; OV and EV can take longer due to organization vetting.
Which endpoint returns the finished certificate?
Once the order reaches an issued state, call GET /api/v1/ssls/certificate.
The Bottom Line
A reliable SSL integration is never just a single call to initialize. Choosing the right product, validating the CSR, making the validation method visible to the customer, tracking status transitions, preventing duplicate orders, and protecting the private key all have to work together. Testing that entire lifecycle end-to-end in OT&E is what keeps both your technical error rate and your support ticket volume low once you're live.
Ready to Grow Your SSL Portfolio?
Set up your reseller account, review the current SSL product lineup, and test the integration against your own sales flow.
Explore the SSL Reseller program.
Have integration questions? Reach out to the Domain Name API technical team.
