Testing your integration
Before making the switch and going live, you should test your integration, using the test account and credentials that we provided you with. Below is a list of test cases that you should follow to help with this.
Please note that scenarios with the ⚠️ icon require our assistance in order to be properly completed because some steps must be executed on our side. So please, after your internal validation, contact us for a final validation session before Go Live.
Authorization and token handling
Here you can find scenarios to test your implementation of the user authorization flow.
| # | Steps | Expected result |
|---|---|---|
| 1.1 | User clicks an "authorize" button/link available in your application's screen | - User is taken to the site's authentication/authorization screen defined in the APP |
| 1.2 | After authenticating in the site, user authorizes your application | - User is redirected back to your app with a success message saying that a connection with the portal was successfully established |
| 1.3 | Execute any operation with a valid access token | - User is able to do any operation |
| 2 ⚠️ | Execute any operation with an expired access token | - Your application should automatically renew the access token using the refresh token and retry the operation - Refresh token can be used only one-time |
| 3 ⚠️ | Using the provided test account, revoke the authorization directly in the site and execute any operation afterwards | - Your application should notify the user that his authorization is no longer valid - Take the user to the authorization flow - Make sure that the "authorize" button/link is now available to the user |
Posting ads
The following scenarios cover the basics of the ad posting flow.
| # | Steps | Expected result |
|---|---|---|
| 1 ⚠️ | Post an ad with a missing mandatory field (such as the title or description) | - Ad is not properly published on the site - Validation error is properly displayed in your application |
| 2 | Post a new ad with all mandatory fields | - Ad is properly published on the site - Ad status is properly displayed in your application as "published" |
| 2.1 | Post a new ad with exact location | - Ad is properly published on the site - Ad status is properly displayed in your application as "published" |
| 2.2 | Post a new ad with relative location | - Ad is properly published on the site - Ad status is properly displayed in your application as "published" |
| 3 | Post an ad with consultant contact | - Ad is properly published on the site with the consultant contact - Ad status is properly displayed in your application as "published" |
| 3.1 | Post an ad with an invalid image for consultant contact | - Ad is not properly published - Error is properly displayed in your application |
| 4 | Post/Activate an ad that became available again, after being marked as: - sold - leased - reserved | - Ad became available again, on CRM - Ad is properly published (or activated) from the site - Ad status is properly displayed your application as "published" |
Updating ads
The following scenarios cover everything that has to do with updating already published ads.
| # | Steps | Expected result |
|---|---|---|
| 1.1 | Change the content (like the description or price) of a published ad and update it | - Ad is properly updated on the site |
| 1.2 | Change images order in a published ad and update it | - Images order is changed on the site |
| 1.3 | Change the image to a new one in a published ad and update it | - Image is changed on the site |
| 1.4 | Change consultant information of a published ad and update it | - Ad is properly updated on the site |
| 2 | Update an ad that's was not successfully posted (NOT_POSTED) | - Your application shouldn't allow this operation / should send a POST request instead of a PUT |
| 3 ⚠️ | Update an ad that's still in a transient state (such as TO_POST) | - Your application shouldn't allow this operation / should show an appropriate message |
| 4 ⚠️ | Update an ad that has been removed on the site (for ex. with state.code "removed_by_user") | - Your application shouldn't allow this operation / should show an appropriate message |
| 5 ⚠️ | Update an ad that has been moderated on the site (for ex. with state.code "moderated_by_admin") | - Your application shouldn't allow this operation / should show an appropriate message to the user contact their site account manager to remove the moderation |
Deleting ads
The following scenarios cover everything that has to do with removing ads.
| # | Steps | Expected result |
|---|---|---|
| 1 | Delete an ad that has been successfully published | - Ad is removed from the site - Ad status is properly displayed your application as "not published" |
| 1.1 | Delete/Deactivate an ad that has checked as: - sold - leased - reserved | - Ad is sold, leased or reserved on CRM - Ad is removed (or deactivated) from the site - Ad status is properly displayed your application as "not published" or "removed" |
| 2 ⚠️ | Delete an ad that's still in a transient state (such as TO_POST) | - Your application shouldn't allow this operation / should show an appropriate message |
| 3 ⚠️ | Delete an ad that has already been removed on the site (for ex. with state.code "removed_by_user") | - Your application shouldn't allow this operation / should show an appropriate message |
Handle advert state changes
These scenarios are all about the advert lifecycle, and you will need some help to complete them. Please contact us to schedule a demo session with us.
| # | Steps | Expected result |
|---|---|---|
| 1⚠️ | Ad is moderated by our quality team | - Ad status is properly displayed in your application as "moderated" - Moderation reason is displayed in your application |
Receive and display leads
The following scenarios cover the integration of leads in your application.
| # | Steps | Expected result |
|---|---|---|
| 1 | Send a lead/message from the site to an ad that was previously published form your application | - Lead is received and displayed in your application with all the information (name, phone, email) |
Category and attribute mapping
Categories and attributes are very important to get right from the start. Given that it's difficult to publish and verify all possible combinations, we ask you to provide us your mapping tables (i.e. your categories and attributes mapped to our taxonomy URNs so that we can validate them internally and give you improvement suggestions when necessary.
Updated 8 months ago