The Trustico® Partner Ordering Application Programming Interface (API) places SSL Certificate orders directly from your own systems. An order arrives priced against your account, paid from your Trustico® Prepaid Credit, and processed exactly as any other Trustico® order.
It is built for partners who order regularly and would rather submit each order from their own platform than complete a form by hand. Every request is made over Hypertext Transfer Protocol Secure (HTTPS) and every response is returned as JavaScript Object Notation (JSON).
This page describes what the Application Programming Interface (API) does and how it behaves. The reference documentation carries the full request and response detail, along with working examples in several languages. Read The Ordering API Documentation 🔗
Eligibility and Access
Access requires an approved Trustico® partner account on the current platform. The ordering Application Programming Interface (API) does not connect to legacy systems, and a key issued for any earlier platform will not work against it.
Approval is required before use. Keys are issued individually after review, and a key may be revoked at any time, taking effect on the next request received. Learn About The Trustico® Partner Service 🔗
If you do not yet hold a partner account, one is created before an Application Programming Interface (API) key can be considered. Learn About Creating a Partner Account 🔗
The Four Endpoints
Two endpoints describe the product catalog and need no key at all. The two that act on your account carry your key and are server to server only, which means a browser cannot call them.
The first lists every orderable product family. The second confirms one product code and returns the exact field names, validation methods and name limit that apply to it.
The third places an order. The fourth returns the orders you have placed, along with the reference each SSL Certificate is assigned once issuance begins.
A complete integration therefore reads the catalog, confirms the chosen product, submits the order, then polls for the reference it needs afterwards.
Exact paths, request shapes, response bodies and status codes are all set out in the reference documentation, which stays current as the endpoints develop. Read The Endpoint Reference 🔗
Authentication
Every request that touches your account carries your issued key in an X-Api-Key header. A missing header and a key that is not accepted both answer with a refusal, and the refusal never states which of the two occurred.
That silence is deliberate. A response that distinguished an unknown key from a revoked one would tell anyone testing keys which of their guesses existed.
Important : Your key is an account credential. Anyone holding it can place orders paid from your Trustico® Prepaid Credit. Store it as a secret on your server and never place it in code that reaches a browser.
If you believe a key has been exposed, request a replacement immediately rather than waiting for evidence of misuse.
Protection Against Duplicate Orders
Every ordering request also carries an Idempotency-Key header of your own choosing. One key represents one order intent, and the protection is remembered against the Application Programming Interface (API) key the request arrived with.
Presenting the same key again with the same body returns the current state of that one request. It never creates a second order and never charges you twice, which makes a retry safe by default rather than safe only when you are careful.
Presenting the same key with a different body is refused as a conflict, because the two cannot both be the single intent that key represents. A corrected order is submitted under a new key.
Warning : Never generate a fresh key to retry a timeout. A timeout means the outcome is unknown and the order may already exist. Retrying the same key resolves that safely, whereas a fresh key is the one way to place a duplicate order through this Application Programming Interface (API).
The same caution applies when a key is replaced. A replacement key carries no memory of the previous key's requests, so any retry still in flight must finish on the old key before you switch across.
Identifying the Product You Want
Products are identified by a code built from three parts : the product family, a three digit count of additional names where the family supports them, and the term in months. A single site product omits the middle part.
The catalog endpoint returns every family with the terms and name counts each one accepts, alongside a real example code. Because the list is generated from the same product data the ordering endpoint enforces, the two cannot drift apart.
Rather than assume a code you have constructed is correct, confirm it against the second endpoint. That response also states the exact field names your order must use, the validation methods the product accepts, and the maximum number of names the order may carry.
Submitting Orders
An order carries one product and a quantity of one. Where several SSL Certificates are wanted, each is submitted as its own request under its own idempotency key.
The fields you supply are exactly those the product advertises, and an unrecognized field name is refused rather than quietly ignored. A typographical error in a field name therefore cannot weaken an order without your knowledge.
Checks that can be made before any money moves are made before any money moves. A name count above the product limit, a malformed domain name, or an unknown product code is refused up front, with the response naming the specific problem rather than describing it generally.
A Certificate Signing Request (CSR) is required for the products that use one, and it is generated on the server where the SSL Certificate will be installed. Learn About Certificate Signing Requests 🔗
Choosing Validation Within the Order
Domain Control Validation (DCV) is chosen inside the order itself rather than afterwards. The primary domain name carries its own choice, and where additional names are present each one carries a choice of its own, in the same order the names were given.
A single value expresses both the method and its target. Supplying a method name selects that method, while supplying an approver e-mail address selects e-mail validation, because an address already states which method it belongs to.
Only the five standard approver addresses are accepted, at the domain name itself or at a parent domain down to the registrable name. Methods may be mixed freely across the names on one order. Learn About The Validation Procedure 🔗
An internationalized domain name may be supplied in either its native or its encoded form for the file and Domain Name System (DNS) methods. E-Mail validation requires the encoded form for both the domain name and the approver address, because approver addresses are calculated from the encoded name.
Payment from Trustico® Prepaid Credit
An order placed through the Application Programming Interface (API) is priced against your account and paid from your Trustico® Prepaid Credit, unless a separate payment arrangement or agreement exists on your account.
Where credit covers the order, it is created already paid, with no invoice step and no separate payment call. Explore Trustico® Prepaid Credit 🔗
Where your balance and any overdraft do not cover the order, the response states the shortfall and the currency it is quoted in, and the order is held for you rather than discarded.
Once the balance covers the shortfall, retrying the same key re-checks the order against your new balance and completes it. Nothing needs to be rebuilt, and no second order is created by the retry.
Order Progress After Placement
The lookup endpoint returns your recent order requests, newest first, each carrying its status, its order name, and every SSL Certificate on it. Paging further back uses a reference echoed from the previous response rather than one you construct.
Each SSL Certificate carries a Certificate Authority (CA) Reference, assigned shortly after the order completes. It is empty until then, so an integration polls until it appears rather than expecting it in the ordering response.
For a traditional SSL Certificate, that reference is what the tracking system Application Programming Interface (API) authenticates with, alongside the domain name and the brand. Learn About The Tracking System API 🔗
Note : On a Certificate as a Service (CaaS) order the reference identifies the license at the Certificate Authority (CA) and nothing more. Those SSL Certificates are managed entirely by your own Automated Certificate Management Environment (ACME) client, so a tracking system call carrying that reference is refused.
Use the reference on a Certificate as a Service (CaaS) order for support and reconciliation instead. Learn About Certificate as a Service 🔗
Only orders placed through this Application Programming Interface (API) appear in the lookup. Orders placed in the store are delivered through the standard order channels as usual.
Intended Failure Handling
Each refusal carries a code, and the documentation states for every code whether the correct response is to retry the same key, to submit under a new key, or to stop and contact us.
The distinction matters more than it first appears. Anything refused before payment is corrected and resubmitted under a new key, because the original key faithfully replays the same refusal.
Anything uncertain after payment is retried under the same key, because that retry is what settles the outcome. Your credit is safe in those cases, and the retry either completes the order or reports it accurately.
One case is deliberately not retryable. Where a held order's total has changed while it waited, the same answer repeats until a person resolves it, so looping the request achieves nothing.
Rate Limits and Acceptable Use
Each endpoint carries a short term burst limit and a longer sustained limit, and the two account endpoints additionally carry a limit against your key. A response that reaches a ceiling states how long to wait before retrying.
The current figures are published in the reference documentation and may be adjusted at any time without prior notice, so an integration should read the wait period from the response rather than assume a fixed rate.
Important : Only genuine credentials may be used, and repeated calls that fail because invalid information was supplied may result in suspension or revocation of your key. Placing an order without the permission of the account holder is a breach and results in immediate termination of access.
Partners remain responsible for the SSL Certificates they order on behalf of others, exactly as they are for orders placed by hand. Learn About Partner Responsibilities 🔗
Processing After Submission
Nothing downstream is different. The order proceeds through validation and issuance exactly as any Trustico® order, and the standard order confirmation is sent as usual.
Your Trustico® Prepaid Credit dashboard and statement record the payment against the real order number, so reconciliation works the same way for orders placed programmatically as for those placed by hand.
Ongoing management of an issued SSL Certificate happens in the tracking system rather than through this Application Programming Interface (API), which exists for ordering alone. Learn About The Tracking System 🔗
Reading the Reference Documentation
The documentation carries every field, every response code, and working examples in three languages that rewrite themselves around your own product code and domain name as you read.
The product catalog shown in the documentation is generated live each time the page loads, so it always reflects what the ordering endpoint currently accepts.
Requesting Access
To apply for an ordering Application Programming Interface (API) key, complete the form below with your organization details, your partner account information, and a short description of the integration you intend to build.
Trustico® reviews each request individually and issues a key directly to approved partners. Describing your intended order volume and the platform you are integrating with helps that review proceed without further questions.
