Security & Authentication

ShipStation takes security very seriously, which is why we require all API requests to be made using HTTPS and TLS 1.1 or higher. We also give you the ability to create and revoke API keys quickly and easily via your account API settings.

ShipStation uses TLS (Transport Layer Security) to encrypt all request and response data. This keeps your sensitive data secure and encrypted - including payment data and customer PII (Personally Identifiable Information) such as addresses and phone numbers.

TLS significantly reduces the risk of data being intercepted or spied upon by third parties by ensuring the following:

• All traffic between your server and ShipStation is encrypted.
• Data payloads are checked for integrity to ensure they have not been modified en route.
• Ownership of the api.shipstation.com domain is verified against ShipStation's security certificate to ensure you are communicating with the right recipient.

ShipStation requires HTTPS and TLS v1.1 or higher for all API calls. This means that all API calls must be made to https://api.shipstation.com, not http://.

To authenticate yourself to ShipStation you need to include an API-Key header in each API call. If you don't include a key when making an API request, or if you use an incorrect or expired key, ShipStation will respond with a 401 Unauthorized error.

For example, here's an API request to get a rate with a shipment ID. Notice the API-Key header in the request.

POST /v2/rates HTTP/1.1
Host: api.shipstation.com
API-Key: __YOUR_API_KEY_HERE__
Content-Type: application/json

{
"shipment_id": "se-123",
"rate_options": {
  "carrier_ids": [
    "se-123890"
  ]
}
}

You can generate and copy your API keys from your ShipStation account settings.

ShipStation provides API keys for two different API versions:

• ShipStation V2 API Key: Used to access the current ShipStation V2 API. You can have one V2 key active at a time.
• ShipStation V1 API Keys (legacy): Used to access the legacy ShipStation V1 API (legacy). You can have two sets of V1 credentials active at a time. The V1 API is deprecated and will be removed in the future.

Since the ShipStation platform does not offer sandbox environments, all ShipStation V2 API operations occur in production and may incur real costs. We recommend these practices when testing:

• Use low-cost shipping options for test labels
• Void test labels immediately using the void label endpoint
• Start with small volumes during development
• For initial development, consider using standalone carrier connections such as UPS/FedEx that typically bill on carrier scan-in rather than label creation (confirm billing terms with your carrier account representative)

Your API key give full access to ShipStation's functionality and therefore should be guarded in the same way you would guard a password or other application credentials.

• Limit who has access to your API key and to the ShipStation account settings.
• Store your keys in a safe place, such as a credential store or key vault.
• Don't hard-code API keys in your source code or config files.
• Ensure that your keys are kept out of any version control system, such as GitHub.

If your application runs on users' desktops, mobile devices, or web browsers, then your app's network traffic could be visible to your users - including your API keys. For this reason, we advise that you only call ShipStation API from your server-side code, which runs safely within your network infrastructure.

Many customers develop client-side applications for interacting with the ShipStation API. For example, you may have a web app or mobile app that your customers use to create shipping labels through ShipStation. If this is the case, make sure all requests to ShipStation are sent from your server and not directly from the client application.

The main reason for this is that you would need to expose your API key to the client. To protect your account from unauthorized access you should never expose your API key to any client application.

The other reason is that web browsers and mobile apps will not allow a web page to access a resource on an other domain.

For example, if your app runs at https://my-app.com and you try to make a request to the ShipStation API at https://api.shipstation.com, the browser will generate an error because your domain, my-app.com, is different from the domain to which you are sending the API request, api.shipstaiton.com. This prevents other web pages you visit from gaining access to the resource - a protection for both your client and the ShipStation API.

One solution is to host your own API on the same domain as your application. Your client application interacts directly with your API and your backend server makes requests to ShipStation. In this manner, your API is a layer between your client application and ShipStation.

Some APIs may implement CORS (Cross Origin Resource Sharing) to allow web browsers and mobile applications to call the API directly. However, this is not the best practice for keeping private APIs like ShipStation secure.