About Autohost's public API
The Autohost API is meant to provide simple access to clients and partners using custom integrations and tools. The API functionality is built to accept most verification data points and process each reservation through the Screening AI.
Accessing the API is meant for users who do not wish to take advantage of the full hosted Guest Portal (GP) functionality and are willing to forgo the use of the guest-facing white labeled portal.
Note: API usage does pose a number of limitations on functionality and verifications that cannot be processed without the guest/booker accessing the Guest Portal. These include, but are not limited to the following: fraud detection, payment verification, security deposit, file upload/document collection, legal rental agreement.
Important Links
Generate API keys at:
https://portal.autohost.ai/settings
Technical Documentation
New account creation and onboarding
-
A new Autohost (AH) account will be created for you.
-
Account setup: settings and preferences (with the help of AH's customer support and success team)
-
Add billing details.
-
Configure account settings and enable necessary add-ons.
-
Set up business rules, if applicable.
-
Create custom domain for GP (if integration is using GP or messaging).
-
-
Create API keys (Generate via Settings > API).
-
Customer will create listings on AH using the API (NOTE: This is optional. Alternatively, listing details can be included with each reservation request.)
API integration workflow - Standard
-
Reservation comes in via API.
-
Precondition: Listing must either exist on the account and be enabled, or be embedded in the API reservation request (otherwise, system will default to a dummy listing).
-
-
Reservation is created or updated in AH.
-
API response will be sent with the AH reservation ID (due to HTTP being synchronous and requiring a quick reply).
-
-
Reservation is then sent to be processed by the Screening AI.
-
Tests are run and/or scheduled (depending on the verifications selected).
-
Verification status is computed.
-
Results are saved.
-
-
Customer can then access verification results:
-
Webhook sent with verification statuses, if provided; or
-
Customer makes an API request to the status endpoint.
-
-
At any point, customer can update a given reservation to re-compute verification statuses and risk.
Verification status fields sent via webhook (pushed) or when requested via API (pulled):
Understanding output and status fields
Possible values and meaning of each status field
Status field
"Status" refers to the Autohost verification status. This status is automatically determined by Autohost and is solely dependent on the Screening AI processing all risk factors, available data and the custom business rules set up on the account.
| Value | Meaning |
| pending | Reservation is in the system, but has yet to go through analysis for final status determination. Waiting for additional data/verification results, as per account configuration. |
| verified | All configured verifications were successfully processed with no specific test or rule flagged for review. Guest has been verified, no further action is required. |
| review | Upon analyzing all verifications, one (or more) tests or business rules were flagged for attention. Reservation requires manual review. |
| null | N/A (Temporary status: reservation entered the system but preliminary screening risk analysis hasn’t been run yet). |
Supervised status
"Supervised" refers to the manual override status set by the user. For every reservation, users have the ability to set a supervised status, the value of which should precede the value of the Autohost status. This can either be done manually through the dashboard, programmatically using business rules, or via the API. Normally, a supervised status will be required when a reservation is flagged for review (i.e. Status = 'Review') and a judgement call is required from the user on whether or not to proceed with the booking.
| Value | Meaning |
| approve | Reservation is set to be ‘Approved’ by the manager, either manually, via the API, or through automated business rules. |
| decline | Reservation is set to be ‘Declined’ by the manager, either manually, via the API, or through automated business rules. |
| null | No manual action was taken. The supervised status is null. |
PMS status
"PMS status" refers to the reservation status on the OTA/PMS and affects whether verification tests are to be processed or not, depending on account settings.
| Value | Meaning |
| CONFIRMED | Reservation is currently confirmed. It will show on the reservations tab inside the dashboard and qualify to go through the Screening AI risk analysis. |
| CANCELED | Reservation has been canceled. Screening AI will not run again and the reservation will no longer appear on the dashboard. Note that the reservation will still exist on the account and details can be retrieved if needed. |
| INQUIRY | This only applies to reservations from OTAs that allow inquiries. The reservation will not show on the dashboard, but details can be retrieved if needed. Unless configured otherwise, Screening AI will run preliminary analysis before additional data becomes available (usually upon PMS status changing to ‘Confirmed’). |
Making business decisions based on the verification statuses
This will depend on each user’s internal business practices and risk tolerance.
API Request Parameters
| Parameter | Allowed values | Description |
| sync | "1" | Synchronous execution; response will be returned immediately. This should be avoided whenever possible as this is a slower and heavier operation, and may result in reservation duplication. |
| callback | "hxxps://example.com/?id=1" | Webhook URL to send data once on completion. |
| skip_gp | "1" | Verification analysis to proceed without dependance on Guest Portal completion. To be included for all reservations where the guest is not expected to complete the portal. |
Note: All POST and PUT requests are asynchronous by default
If you are using Ngrok to test callbacks, note that you’ll need to use a custom subdomain because the free random domains rely on a redirect header sent to the client to point it to another random domain. Ngrok does this by design for security reasons.
Sample request body:
Example request using `curl`:
Example reservation verification with ID using API:
Step 1: Create new reservation with the details on the person you want to vet.
Step 2: Upload front-side of the ID document.
Step 3: Upload back-side of the ID document.
Step 4: Upload selfie image to match against the photo ID uploaded in step 2.
Step 5: Get verification status and details.
And that's it!