Infrastructure
Wineshipping’s API is hosted in Azure on high-availability, scalable cloud infrastructure to ensure maximum performance. Application functionality is exposed through secure API endpoints and encrypted SSL browser sessions. The Wineshipping API has been designed for easy integration with external applications through a collection of RESTful operations.
Robust Architecture
- Available 24/7
- Secure Authentication and Access
- Auto-scale for increased demands
- Interactive modeler for integration design
- Full lifecycle testing support
Environment & Endpoints
All API operations are RESTful and support secure HTTPS requests. The responses are JSON along with standard HTTP code.
The Production API should be used for all production transaction communications.
- Base URL: https://api.wineshipping.com/v3
The Development environment should be used for integration development and testing.
- Base URL: https://api-test.wineshipping.com/v3
- API documentation and Metadata OpenAPI spec (aka Swagger spec) are available on this site
Authentication
Wineshipping API methods require credentials to be passed as part of the request body in an Authentication object
Request
| Name | Type | Required | Description |
|---|---|---|---|
| Authentication | Authentication Object | Yes | Credentials are required to execute API operations. |
Authentication Object
| Name | Type | Required | Description |
|---|---|---|---|
| UserKey | String | Yes | User Key from Wineshipping. |
| Password | String | Yes | Password from Wineshipping. |
| CustomerNo | String | Yes | Customer account number |
Response
| Name | Type | Description |
|---|---|---|
| Operation Response Body | Response Body | Contains standard HTTP status codes indicating success or failure of the API operation call. If response indicates a failure, an error message will be supplied. |
Rate Limits & Quotas
The Wineshipping API is designed to accommodate many businesses within the wine industry. It can scale effectively to handle spikes in order traffic like your club orders as well as high volume seasonal activities. There are no hard limits on the number of requests, but we do implement rate limiting in both testing and production. Quotas may be introduced in the future.
When a call rate is exceeded, the caller receives a 429 Too Many Requests response status code. This is most often triggered by immediately calling GetDetails after submitting an order. Instead of execessively polling for status updates we encourage you to use our event driven tracking webhooks to retrieve order status information.
Below is the table of rate-limits for each method:
| OperationName | Env | Calls | Renewal-Period |
|---|---|---|---|
| GetDetails | TEST | 20 | 120 |
| GetDetails | PROD | 600 | 60 |
| GetCarrierLocations | PROD | 300 | 60 |
| GetInventoryStatus | PROD | 100 | 60 |
| GetPackages | PROD | 100 | 60 |
| GetSellabe | PROD | 100 | 60 |
| GetPackingSlipWithDeclaredValue | PROD | 300 | 30 |
| SalesOrderGenerateJitLabel | PROD | 300 | 30 |
| Validation | PROD | 300 | 30 |
| GetDeliveryEstimates | PROD | 100 | 30 |
| GetInventoryDetails | PROD | 100 | 30 |
| GetInventoryTransactions | PROD | 100 | 30 |
| GetOrdersOnHold | PROD | 100 | 30 |
| GetReturns | PROD | 100 | 30 |
The renewal period is the length in seconds of a sliding window during which the number of allowed requests should not exceed the value specified in calls. For example then a call to GetDetails in PROD owld fail if its the 601st call in a minute.