Search Results
WSDLs and Endpoints
WSDLs
End Points
| SWS End Points | |
|---|---|
| SLC | https://slc.centershift.com/store40/SWS.asmx |
| CS10 | https://cs10.centershift.com/store40/SWS.asmx |
| Sandbox | https://sbx.centershift.com/sbx/SWS.asmx |
| SWS2 End Points | |
| SLC | https://slc.centershift.com/store40/StoreService.svc |
| CS10 | https://cs10.centershift.com/store40/StoreService.svc |
| Sandbox | https://sbx.centershift.com/sbx/StoreService.svc |
| Bulk Data End Points | |
| SLC | https://slc.centershift.com/Store40/bulkdata.asmx |
| CS10 | https://cs10.centershift.com/Store40/bulkdata.asmx |
| Sandbox | https://sbx.centershift.com/sbx/bulkdata.asmx |
Overview: Using Yardi Store Web Services (SWS)
Overview: Using the Store Web Services (SWS)
General Information and Tips
Lookup User Request Object*
*Note: This object is required in almost all SWS method calls and is used to confirm access.
Contacting Store Web Service Support
Workflow for Creating a Reservation or Rental
WSDLs and Endpoints
SWS2 API Setup Help
Gateway Controls
Maintenance News/Updates
September 11, 2019
Added Webhook functionality to the SWS API. Currently only available for making a reservation. Whenever a quote, reservation or in-process rental is created, a message will appear on your target website with the details of the rental. Use the WebhooksSubscribe and WebhooksUnsubscribe methods.
February 21, 2018
- New SWS methods being added pertaining to the SMS text feature. See the update notes at this link.
November 27, 2017
- Three new SWS methods will be added to the API to interact with the waitlist feature. These can only be used if the organization has permissions for the waitlist feature.
August 23, 2017
- This update will introduce a variety of changes and fixes, primarily defect corrections in the application, reports, and SWS methods. The changes to SWS will not require changes to integrated systems.
June 7, 2017
- SWS – New method – GetRentalActivityUnitLevel
Report generated through SWS that will provide the rental activity for a specified group of units and a date range.
- eStore password/eCommerce code encryption
Previously a customer’s eComm code (eStore Password) was displayed in the application and was retrievable by many methods. This item is now being encrypted. If a method would previously return the eCommerce code/eStore password, it will no longer do so.
- SWS – SendEmail
This method gives the option to send multiple types of emails. In the email SWS_RESERVATION_CONFIRMATION, the org information was included in the email, rather than the site information. This will be updated to the site information instead.
- New Store Feature – Waitlist
The waitlist feature will be available in the application after the update. There will be no SWS methods for this feature at this time.
- SWS – New method – GetRemoteDocusignLease
This new method will send a request to DocuSign to have them email the customer a form that can be signed at their leisure, rather than requiring an immediate signature. If you wish to have the customer sign immediately see the GetDocusignLease method.
- SWS – UpdateGatePIN
This update corrects an issue that was reported in regards to being unable to update a gate pin using the SWS method.
- Adding a rule to check for an AutoPay address.
If this rule is set by the site, any new AutoPays will be required to have an address. This will also affect the eStore AutoPay and payment widget. You can check the GetSiteRules method for information on whether a site requires the information or not.
ATTENTION!! Have you tested for the new TLS 1.2 Protocol?
If you haven’t verified that you are ready click here for the testing information. After the February 22, 2017 update, methods called not using this protocol will FAIL.
ATTENTION
Sandbox has new URLS!! Head over to the WSDLs and Endpoints page for the new information or you can continue (for now) to use the same endpoints.
February 22, 2017
With the expected February release of updates to Store Enterprise and Store Advantage, we have modified the process used by eStore and the Store Web Services (SWS) API used by custom web sites that allows tenants to log in. For many years, Yardi has maintained duplicated data in tables to create an organization-level login process. We will remove the tables that duplicated the data and we have created a new relationship table to support the organization-level login process. These data set changes require changes in how data is accessed and relationships are created for eStore users and SWS consumers employing e-commerce on custom websites. Core functionality for both SWS and eStore will not be affected.
All SWS methods will continue to function as they always have. The ECOMM_ID will now be the ACCOUNT_ID; however, code using ECOMM_ID will continue to function as it does now as the ID’s have been replaced globally. This means no code changes should be required.
Delayed till first quarter 2017
There has been a shift in how we handle E-Commerce accounts. The prior way of doing things required a separate table with a lot of duplicated information that frequently got out of sync and caused many issues with how accounts were linked together within the SWS Ecomm methods and the eStore product. In order to resolve these issues, the ecomm tables have been removed. Logging in and out will rely solely on the information in the account’s contact records. In order to link one account to another there is now a form in the Store application. Any reservations made online through an established account to a different site will be automatically linked as well. All methods within SWS and eStore will continue to function as they have in the past, however, anywhere the ecomm_id was returned, the account ID will be returned in it’s place though it will retain the ecomm_id label. No changes to the structure of any of the methods occurred in keeping with backwards compatibility and all methods will continue to provide the same results and perform the same functionality. This will correct many existing bugs that are currently creating or updating erroneous and/or duplicate data. This impacts all methods that currently handle e-commerce account or contact data.
November 16, 2016
Yardi will release an update to the Store management system during the evening hours of Wednesday, November 16, 2016. This is the re-release of the update originally scheduled for October 26 but was aborted due to complications. This update will affect all users in all server environments of Store as detailed in the release notes for this change, which can be found on the News and Updates page of our website. You can navigate to that page by following this link.
While we will continue to send email notifications of all product update events, all release notes can be found on our website. Therefore, we recommend that you check the release notes frequently to remain up-to-date on the most recent changes to our software and our other products and services.
Thank you.
The Yardi Storage Product Management Team
ASMX vs. SVC
The web services in Store are all based on Microsoft’s WCF technology instead of the older ASMX model. While this has been a huge boost in flexibility for Store, it has led to some confusion for some of our clients. In this article, I’ll attempt to explain the differences between the two and the reason why Store 4 is built the way it is. (This may get a little technical, so hang on!) Let’s start at the beginning:
In Store 3.1, the web services were written using ASMX. That allowed us to easily expose all kinds of internal datatypes as XML – and since many of our services returned tables of data, it seemed like a logical solution to simply return .NET DataSet objects to our clients. However, since a .NET DataSet is only defined at runtime, the WSDL schema definitions for those tables don’t know what they will look like. As a result, the WSDL file uses a simple tag to represent the table: <xml:any> This tag is basically the XML equivalent of “Object” or “Var”. It is type-less. It means that when a client calls this service, they will receive a blob of unidentified XML in this location. It is then up to the client to parse through the XML, figure out what it means, and do something with it.
Now, when Microsoft technology is used on the client side, it knows what this XML means and automatically converts it into a .NET DataSet for the client to consume. But for any other clients, the XML coming down from the server has to be parsed manually. It’s not very fun, and no one wants to do it. Because of this, the use of .NET DataSets in XML web services is commonly viewed as a “Microsoft-specific practice” and not very cross-platform compatible (even though technically it can still be used by any client.)
So for Store 4, we decided to go in a direction that is more accessible to the mainstream. We now have clearly-defined XML structures for every request, response, and object we move across the wire. The services should now be completely compatible with any modern web service client technology. Except …
A single, ginormous WSDL file with everything in it is considered by some in the industry to be a bad XML practice. The argument is that the XML should be neatly parsed into a few separate files, and <xml:Import> tags be used to combined them on-the-fly into a single WSDL definition. Microsoft has adopted this philosophy, and the new WCF engine generates its WSDL files in a few distinct pieces – which is then left to the client to compile into a single WSDL contract. The problem is that some (usually older) client-side technologies do not yet support the <xml:Import> command. when these clients connect to a WCF web service, they download the main WSDL file but not all the other related pieces that contain the actual “meat” of the web service. Some clients view this action too as being Microsoft-specific; but it’s actually not, it’s an industry standard.
So – How can a client connect to SWS using older client technology? One flexibility provided to us by WCF is that we can expose our services through multiple endpoints without changing any code. So in addition to the default WCF endpoint (SWS.svc), we can also expose our services using the older ASMX engine (SWS.asmx) with minimal adjustments. And this second, ASMX endpoint generates an almost identical WSDL definition, but as a single file instead of split up into pieces.
Currently we’ve only exposed our main web service bundle in this way (SWS). But over the while we’ll be creating ASMX copies of our other web services as well. The .svc version is still the endpoint we recommend to all our clients; but if you’re having trouble connecting to it, then by all means give the .asmx version a try. Our goal is to provide complete compatibility with all platforms – and we’ll do what we need to do to make that a reality!
Yardi Store Developer eXchange 