ATOM Mobility OpenAPI Beta (1.0.0)

First step of the authentication flow. This endpoint initiates the phone verification process. If successful, it will return a phone_token that must be used in the next step. An SMS verification code will be sent to the provided phone number.

Captcha

Depending on the account configuration, this endpoint may require a captcha to be solved before an SMS is sent. This protects against SMS-pumping / OTP abuse. It is controlled by a single per-account switch, off by default, that applies to API clients only:

• off (default) - captcha is never required here.
• on - every request is challenged, until the number solves one, after which it is skipped for ~12 hours.

Implement the flow below regardless, so enabling the switch does not break your integration.

When a captcha is required, the endpoint responds with HTTP 400 and a body carrying action: "CAPTCHA", a base64-encoded PNG (captcha_img_base64) and a captcha_token - instead of sending an SMS. To continue:

1. Render the image from captcha_img_base64 (prefix it with data:image/png;base64,) and have the user read the characters.
2. Re-send this exact request with two extra fields: captcha (the solved text) and captcha_token (echoed from the challenge response).

An incorrect answer returns HTTP 400 again with action: "CAPTCHA", a message of captcha.invalid and a fresh image + token (retry). A correct answer proceeds as normal and returns the phone_token (200).

Second step of the authentication flow. This endpoint verifies the SMS code sent to the phone number. It requires the phone_token from the previous step and the 6-digit verification code received via SMS. Upon successful verification, it returns a new phone_token that must be used for login or registration.

Final step for new user registration. This endpoint requires the phone_token from the verification check step to confirm phone ownership. Upon successful registration, it returns an authentication token that must be used for all subsequent authorized API calls.

Final step for existing user login. This endpoint requires the phone_token from the verification check step to confirm phone ownership. Upon successful login, it returns an authentication token that must be used for all subsequent authorized API calls.

Authorization for dashboard for openapi flow, using email and password from dashboard

Retrieves user information. Can be accessed in two ways:

1. Using user token obtained from the authorization flow
2. Using secret key with user_id parameter in the request body

Retrieves list of user bookings. Can be accessed in two ways:

1. Using user token obtained from the authorization flow
2. Using secret key with user_id parameter in the request body

Retrieves user payment methods. Can be accessed in two ways:

1. Using user token obtained from the authorization flow
2. Using secret key with user_id parameter in the request body

Sets the payment method the user pays with in the given flow. Can be accessed in two ways:

1. Using user token obtained from the authorization flow
2. Using secret key with user_id parameter in the request body

status is 0 when nothing changed, for example when the payment method already is the default. selected_payment_method always shows the actual default.

Deletes a saved payment method. Can be accessed in two ways:

1. Using user token obtained from the authorization flow
2. Using secret key with user_id parameter in the request body

Not possible while the user has debt or an active ride. If the deleted payment method was the default, the next saved one becomes the default.

Creates a new user account for registration forms where SMS verification is not integrated. This endpoint only requires App-Public-Key header, no user authentication needed. Note: This is an alternative registration method that bypasses the phone verification flow.

Available only with secret key

Available only with secret key. Charges the user's saved payment method and adds the amount to the user wallet, where it covers the user debt first. Without payment_method_id the default payment method is charged, and if the account allows it, the user's other saved payment methods are tried when that charge fails.

Secret key deletion is hard deletion, user token is soft deletion, meaning that user will be deleted in X days

First step of the booking flow. This endpoint returns a list of available rental zones. Each zone includes an ID and title that will be used in subsequent API calls. Only requires App-Public-Key header, no user authentication needed.

Second step of the booking flow. This endpoint returns available vehicle models for the specified timeframe. Requires pick_up_zone_id and return_zone_id from the zones list (they must match as only A-A rentals are currently supported). Only requires App-Public-Key header, no user authentication needed.

Third step of the booking flow. This endpoint creates a new booking for the selected vehicle. Requires both App-Public-Key and Authorization token headers. The request must include pick_up_zone_id and return_zone_id from the zones list, and vehicle_model_id from the available vehicles list.

This endpoint allows cancellation of an existing booking. Requires both App-Public-Key and Authorization token headers. The booking_id can be obtained from the user bookings list retrieved via user/get-user-bookings endpoint.

Retrieves sharing zones as a list. Each zone has one of two shapes:

• Polygon zone - zone_area is a GeoJSON Polygon whose points are [longitude, latitude]; zone_point and zone_radius are null.
• Circular station zone (zone_type = park_place_zone) - zone_point is the center as {"longitude": ..., "latitude": ...} and zone_radius is the radius in meters; zone_area is null.

zone_type in the response is lowercase: parking_zone, no_parking_zone, paid_parking_zone, bonus_zone, speed_limit_zone, no_go_zone or park_place_zone. The zone_types filter takes the uppercase values listed in the request schema. Circular station zones have no filter value, so they are returned only when zone_types is not sent.

Retrieves parking stations, in the same shape the app receives them.

A station with a zone is a circular parking zone carrying its capacity and working time; a station whose zone is null is only a map pin. Unlike get-zones, which returns stations only as zones, this endpoint returns both kinds.

To search a map area, use either h3_index or latitude + longitude + radius_in_km - passing both is rejected, and passing neither returns every station.

Available only with a secret key - this is fleet data of the whole account, not data of the acting user.

Retrieves charging stations (dock stations), in the same shape and with the same slot counts the app map receives them.

available_slots is how many vehicles can still be docked, total_slots also counts the docked vehicles that are ready to ride. Slots that are switched off are not counted, and a station no vehicle model is assigned to is not returned.

Available only with a secret key - this is fleet data of the whole account, not data of the acting user.

Retrieves vehicles information.

Starts a ride. Use either vehicle ID or number.

Ends a ride. Use either vehicle ID or number.

Retrieves the current ride. Available only for active rides.If passed vehicle ID is not in active ride, then will return empty arrays.

Retrieves vehicle pricing. Use either vehicle_id or model_id.

During active ride pause vehicle. Use either vehicle ID or number.

During active ride unpause vehicle. Use either vehicle ID or number.

List the account subscription plans. By default only active plans are returned; the status and vehicle_types filters are available with secret key authentication.

Return a user's past and current subscriptions, newest first. Without a secret key the logged-in user only sees their own history; with a secret key any user_id can be requested.