How do I automate SOLO Server with the web services (API)?

SOLO Server exposes a programmatic interface, usually called the web services or the API, that lets your own systems create and update licenses, look up customers, activate installations, and pull licensing data on a schedule. Most authors use it to connect SOLO Server to an ERP, CRM, e-commerce platform, or internal tooling so that staff never have to log into SOLO Server to issue or change a license.

Quick reference: SOLO Server's API is a set of ASMX web services at https://secure.softwarekey.com/solo/webservices/. You can call them as SOAP, or as a plain form-encoded HTTP POST using each method's "S" variant (for example AddS instead of Add). Every call authenticates with your Author ID plus an API User ID and API User Password, which you create as a dedicated Integration User in SOLO Server. For per-record, real-time operations use the XML web services. For bulk data pulls, use the reports called programmatically with WebServiceLogin=True. There is no published REST/JSON or OpenAPI definition today.

What you can automate

Common integrations built on the web services:

• Create a license when an order is placed in your ERP, CRM, or storefront
• Update an existing license: extend expiration, change activation counts, set custom fields
• Look up or create customer records, and authenticate customers
• Pull license, customer, and activation data into your own database or reporting system

Product configuration is the main thing you cannot automate. Products and Product Options are set up once in the SOLO Server interface, and normally do not change often enough to need an API.

Two different tools, and when to use each

Choosing the wrong one is the most common source of wasted effort, so decide this first.

Use the XML web services for per-record, real-time operations. Creating one license, looking up one customer, activating one installation. These are request-and-response calls your application makes as things happen.

Use programmatic reports for bulk data. Syncing your whole license database into a data warehouse, or a nightly or weekly export. A report call returns the entire dataset in a single response, which is far lighter than looping web service calls per record.

A scheduled bulk sync built out of individual web service calls will be slow and will consume many more API transactions than the equivalent report export.

Before you start: create an Integration User

Web service and report calls authenticate with three values sent on every request:

• Author ID, your SOLO Server account ID
• API User ID
• API User Password

Do not use a staff member's login for this. Create a dedicated Integration User instead. An Integration User is API-only, so it cannot log into the author interface, and SOLO Server generates its API credentials for you. Grant it only the permissions your integration actually needs, for example Add Licenses, Add Single Customer, or Report Access. You can also restrict it to your integration's public IP addresses using the Outside Access field on the user record.

Setup is described under Web Service Security in the Web Services Overview and in Managing Users, Groups, and Email Notifications.

One thing to plan for: an Integration User counts as a user seat on your account, so it may carry the standard per-user fee.

Store these credentials the way you would any other secret, in your platform's credential store rather than in source code or configuration files.

Calling the web services: SOAP or plain HTTP POST

The web services are ASMX endpoints that speak SOAP, and we do not publish an OpenAPI (REST/JSON) definition for them. That matters if your platform expects to import a Swagger or OpenAPI spec, as Salesforce External Services does.

You do not actually need SOAP to call them. Every XML web method also has an "S" variant that accepts the request XML as a plain string over a standard form-encoded HTTP POST. For example, AddS instead of Add. Any language or platform that can make an HTTP POST can call SOLO Server, with no WSDL import and no SOAP envelope.

A plain POST to create a license looks like this:

<code>POST https://secure.softwarekey.com/solo/webservices/XmlLicenseService.asmx/AddS
Content-Type: application/x-www-form-urlencoded

xml=<url-encoded LicenseAdd XML>

Each web method publishes its own help page showing the exact request and response format. Append ?op=<MethodName> to the service URL, for example XmlLicenseService.asmx?op=AddS. Add ?WSDL instead if you want the WSDL for a SOAP client.

When building the request XML, remember that & is an escape character in XML and must be written as & in any input value.

Which web service do I need?

Full method lists and parameters are in the manual: XML License Service, XML Customer Service, XML Activation Service, XML License File Service, and XML Network Floating Service.

Older, non-XML services also exist (Activation Server, Cart Server, Customer Server, License Server). They still work and accept the same form-encoded POST, sending one form field per parameter instead of a single xml field. Use the XML services instead wherever a method exists in both, since the XML versions support newer features. The one case where an older service is still genuinely useful is LicenseServer.AddLicenseAndUnregisteredCustomer, which creates a customer and a license in a single call.

A typical "create a license from an order" sequence

1. Look up the customer with XML Customer Service CustomerSearch, for example by email address.
2. If no customer exists, create one, or use LicenseServer.AddLicenseAndUnregisteredCustomer to do both in one call.
3. Create the license with XML License Service Add or AddS, passing the CustomerID plus ProdOptionID, Quantity, UnitPrice, ActivationCount, and DeactivationCount.
4. Store the returned License ID and Customer ID in your own system as the linking keys. These IDs are stable, so your records stay matched on every future sync.

While you are building, pass IsTestLicense on the Add call so your test runs are flagged as test licenses rather than polluting your real data.

Pulling data in bulk with programmatic reports

Any SOLO Server report can be run programmatically over a standard HTTP GET or POST, returning the whole dataset as CSV or XML in one response. This is the right tool for syncing licensing data into your own database.

Every programmatic report takes the same common parameters:

• WebServiceLogin=True, which flags the request as an API call
• AuthorID, your SOLO Server Author ID
• UserID and UserPassword, your Integration User credentials
• ReportType, which is Csv, XmlElements, or XmlParameters
• StartDate and EndDate, in MM/dd/yyyy format

A weekly CSV pull of licenses looks like this:

<code>https://secure.softwarekey.com/solo/authors/RptExportLicenses.aspx?WebServiceLogin=True&AuthorID=123456&UserID=YourApiUser&UserPassword=YourApiPassword&ReportType=Csv&StartDate=06/16/2026&EndDate=06/23/2026

Each report also has its own filter fields. Accessing Reports Programmatically explains how to read the exact parameter names off the report's own form so you can match them precisely.

For an incremental sync, filter on the Modified date. The Export Licenses report has a Search By option that lets you filter on when a record was last modified rather than when it was entered. A scheduled job that passes a rolling start date and searches by modified date returns only what changed since the last run, which keeps each payload small and your copy continuously in sync. This is the recommended pattern for keeping another system up to date.

Export Activation Data covers activation-level detail. It is limited to a one year range per call, so a historical backfill has to be run in yearly chunks.

What do API calls cost?

Activations and API transactions are metered separately. A programmatic report export or a web service call counts as an API transaction, not an activation, so your integration does not draw down the activation credits your customers use.

Bulk report pulls are unusually cheap in these terms, because a single report call returns the entire dataset in one response no matter how many records come back. A once-a-week export is roughly 4 to 5 API transactions per month.

You can see your account's current usage on your monthly summary page at https://secure.softwarekey.com/solo/authors/RptAuthorMonthlySummary.aspx. Full detail is in API Transaction Policy and Examples.

Sample code

Sample projects for calling the web services and the reports are available on request from support@softwarekey.com, currently covering PHP, Python, and C#. For .NET applications already using the Protection PLUS 5 SDK, the SDK includes helpers for calling SOLO Server web services directly: see PLUSManaged: Calling SOLO Server XML Web Services or PLUSNative: Calling SOLO Server XML Web Services.

You can also request sample PHP and Python code from us.

When a call fails

Web service calls return a numeric result code rather than an HTTP error. Look the code up in SOLO Server Automation web service error and return codes.

If calls that used to work start returning error code 5000, see I recently started receiving error code 5000 when calling the web services. That one is almost always about your account's Encryption Key.

Common questions

Does SOLO Server have a REST API?

Not today. The current web services are ASMX endpoints that speak SOAP, and there is no published REST/JSON or OpenAPI definition. You can still call every XML web method over a plain form-encoded HTTP POST using its "S" variant, which is what most non-.NET integrations do. A RESTful API is planned as part of a broader SOLO Server modernization, but there is no release date to share yet.

Can I import an OpenAPI or Swagger spec into my integration platform?

No. Because there is no OpenAPI definition, platforms that require one (such as Salesforce External Services) cannot register SOLO Server directly. Two workarounds: write a small piece of code in the platform itself that makes the HTTP POST (in Salesforce, an invocable Apex action used from Flow Builder), or stand up a thin wrapper such as an Azure Function or AWS Lambda that exposes a REST endpoint with an OpenAPI spec and forwards to SOLO Server. The in-platform code path is usually simpler unless you already run middleware.

Do the web services work with SOLO Server Self-Hosted?

Yes. The same web services are available on SOLO Server Shared URL, SOLO Server Dedicated URL, and SOLO Server Self-Hosted. Only the hostname differs, since self-hosted and Dedicated URL accounts call their own domain rather than secure.softwarekey.com.

Can I create products and product options through the API?

No. Product and Product Option configuration is done in the SOLO Server interface. In practice this is a one-time setup that rarely changes, so it seldom blocks an integration.

Which login do I use for API calls?

Neither your author login nor a customer login. Create a dedicated Integration User in SOLO Server, which is API-only and cannot sign into the author interface. Its API User ID and API User Password are what your integration sends with each request.

How do I test an integration without creating real licenses?

Pass IsTestLicense when creating a license so the record is flagged as a test license.

Related articles

• Getting Started with SOLO Server Automation
• API Transaction Policy and Examples
• SOLO Server Automation web service error and return codes
• I recently started receiving error code 5000 when calling the web services
• Importing license and customer data into SOLO Server Automation