get_around_owner 1.0.0 → 1.0.3

data/docs/UnavailabilitiesApi.md

@@ -2,60 +2,95 @@
 
 All URIs are relative to *https://api-eu.getaround.com/owner/v1*
 
-| Method | HTTP request | Description |
-| ------ | ------------ | ----------- |
-| [**created_unavailability_post**](UnavailabilitiesApi.md#created_unavailability_post) | **POST** /createdUnavailability | Unavailability created on one of your cars |
-| [**deleted_unavailability_post**](UnavailabilitiesApi.md#deleted_unavailability_post) | **POST** /deletedUnavailability | Unavailabilities deleted on one of your cars |
+Method | HTTP request | Description
+------------- | ------------- | -------------
+[**create_unavailabilities**](UnavailabilitiesApi.md#create_unavailabilities) | **POST** /cars/{car_id}/unavailabilities.json | Create Unavailability related to a car between dates
+[**destroy_unavailability**](UnavailabilitiesApi.md#destroy_unavailability) | **DELETE** /cars/{car_id}/unavailabilities.json | Destroy Unavailability related to a car between dates
+[**get_unavailabilities_for_car**](UnavailabilitiesApi.md#get_unavailabilities_for_car) | **GET** /cars/{car_id}/unavailabilities.json | Find Unavailabilities related to a car between dates
 
+# **create_unavailabilities**
+> create_unavailabilities(car_id, opts)
 
-## created_unavailability_post
+Create Unavailability related to a car between dates
 
-> created_unavailability_post(opts)
-
-Unavailability created on one of your cars
-
-### Examples
+Set a car as unavailable between 2 dates
 
+### Example
 ```ruby
-require 'time'
-require 'get_around_owner'
+# load the gem
+require 'getaround-api'
+# setup authorization
+GetAroundOwner.configure do |config|
+end
 
 api_instance = GetAroundOwner::UnavailabilitiesApi.new
-opts = {
-  getaround_unavailabilities_created:  # GetaroundUnavailabilitiesCreated | This event is triggered whenever an unavailability is created (through the API or directly in the app/website). It shows the unavailability that has just been created, with the same timestamps as those entered by the user. It does not show the changes of other potential overlapping unavailabilities. For example: if an unavailability was already set between June 10 and June 20, and if the user creates a new one between June 18 and June 22, this webhook will only send information about the newly created June 18 - June 22 unavailability. It will not show that, under the hood, the unavailability from June 10 to June 20 has be deleted, and that a new unavailability from June 10 to June 22 has been created.
+car_id = GetAroundOwner::null.new #  | ID of car
+opts = { 
+  body: GetAroundOwner::CarIdUnavailabilitiesJsonBody.new # CarIdUnavailabilitiesJsonBody | Unavailability to create
 }
 
 begin
-  # Unavailability created on one of your cars
-  api_instance.created_unavailability_post(opts)
+  #Create Unavailability related to a car between dates
+  api_instance.create_unavailabilities(car_id, opts)
 rescue GetAroundOwner::ApiError => e
-  puts "Error when calling UnavailabilitiesApi->created_unavailability_post: #{e}"
+  puts "Exception when calling UnavailabilitiesApi->create_unavailabilities: #{e}"
 end
 ```
 
-#### Using the created_unavailability_post_with_http_info variant
+### Parameters
+
+Name | Type | Description  | Notes
+------------- | ------------- | ------------- | -------------
+ **car_id** | [****](.md)| ID of car | 
+ **body** | [**CarIdUnavailabilitiesJsonBody**](CarIdUnavailabilitiesJsonBody.md)| Unavailability to create | [optional] 
+
+### Return type
+
+nil (empty response body)
+
+### Authorization
+
+[bearerAuth](../README.md#bearerAuth)
+
+### HTTP request headers
+
+ - **Content-Type**: application/json
+ - **Accept**: Not defined
+
+
+
+# **destroy_unavailability**
+> destroy_unavailability(car_id)
 
-This returns an Array which contains the response data (`nil` in this case), status code and headers.
+Destroy Unavailability related to a car between dates
 
-> <Array(nil, Integer, Hash)> created_unavailability_post_with_http_info(opts)
+Set a car as available between 2 dates
 
+### Example
 ```ruby
+# load the gem
+require 'getaround-api'
+# setup authorization
+GetAroundOwner.configure do |config|
+end
+
+api_instance = GetAroundOwner::UnavailabilitiesApi.new
+car_id = GetAroundOwner::null.new #  | ID of car
+
+
 begin
-  # Unavailability created on one of your cars
-  data, status_code, headers = api_instance.created_unavailability_post_with_http_info(opts)
-  p status_code # => 2xx
-  p headers # => { ... }
-  p data # => nil
+  #Destroy Unavailability related to a car between dates
+  api_instance.destroy_unavailability(car_id)
 rescue GetAroundOwner::ApiError => e
-  puts "Error when calling UnavailabilitiesApi->created_unavailability_post_with_http_info: #{e}"
+  puts "Exception when calling UnavailabilitiesApi->destroy_unavailability: #{e}"
 end
 ```
 
 ### Parameters
 
-| Name | Type | Description | Notes |
-| ---- | ---- | ----------- | ----- |
-| **getaround_unavailabilities_created** | [**GetaroundUnavailabilitiesCreated**](GetaroundUnavailabilitiesCreated.md) | This event is triggered whenever an unavailability is created (through the API or directly in the app/website). It shows the unavailability that has just been created, with the same timestamps as those entered by the user. It does not show the changes of other potential overlapping unavailabilities. For example: if an unavailability was already set between June 10 and June 20, and if the user creates a new one between June 18 and June 22, this webhook will only send information about the newly created June 18 - June 22 unavailability. It will not show that, under the hood, the unavailability from June 10 to June 20 has be deleted, and that a new unavailability from June 10 to June 22 has been created. | [optional] |
+Name | Type | Description  | Notes
+------------- | ------------- | ------------- | -------------
+ **car_id** | [****](.md)| ID of car | 
 
 ### Return type
 
@@ -63,73 +98,70 @@ nil (empty response body)
 
 ### Authorization
 
-No authorization required
+[bearerAuth](../README.md#bearerAuth)
 
 ### HTTP request headers
 
-- **Content-Type**: application/json
-- **Accept**: Not defined
+ - **Content-Type**: Not defined
+ - **Accept**: Not defined
 
 
-## deleted_unavailability_post
 
-> deleted_unavailability_post(opts)
+# **get_unavailabilities_for_car**
+> UnavailabilitiesIndex get_unavailabilities_for_car(start_date, end_date, car_id, opts)
 
-Unavailabilities deleted on one of your cars
+Find Unavailabilities related to a car between dates
 
-### Examples
+Find between 2 dates when you’ve set a car as unavailable
 
+### Example
 ```ruby
-require 'time'
-require 'get_around_owner'
+# load the gem
+require 'getaround-api'
+# setup authorization
+GetAroundOwner.configure do |config|
+end
 
 api_instance = GetAroundOwner::UnavailabilitiesApi.new
-opts = {
-  getaround_unavailabilities_deleted:  # GetaroundUnavailabilitiesDeleted | This event is triggered whenever an unavailability is deleted (through the API or directly in the app/website). It shows the unavailability that has just been deleted, with the same timestamps as those entered by the user. It does not show the changes of other potential overlapping unavailabilities. For example: if an unavailability was already set between June 10 and June 20, and if the user deletes an unavailability between June 18 and June 22 (to set their car as available between this dates), this webhook will only send information about the newly deleted June 18 - June 22 unavailability. It will not show that, under the hood, the unavailability from June 10 to June 20 has be deleted, and that a new unavailability from June 10 to June 18 has been created.
+start_date = GetAroundOwner::null.new #  | Start date and time in [ISO8601 format](https://www.iso.org/iso-8601-date-and-time-format.html)
+end_date = GetAroundOwner::null.new #  | End date and time in [ISO8601 format](https://www.iso.org/iso-8601-date-and-time-format.html)
+car_id = GetAroundOwner::null.new #  | ID of the car
+opts = { 
+  page: GetAroundOwner::null.new, #  | Page number
+  per_page: GetAroundOwner::null.new #  | Page size
 }
 
 begin
-  # Unavailabilities deleted on one of your cars
-  api_instance.deleted_unavailability_post(opts)
-rescue GetAroundOwner::ApiError => e
-  puts "Error when calling UnavailabilitiesApi->deleted_unavailability_post: #{e}"
-end
-```
-
-#### Using the deleted_unavailability_post_with_http_info variant
-
-This returns an Array which contains the response data (`nil` in this case), status code and headers.
-
-> <Array(nil, Integer, Hash)> deleted_unavailability_post_with_http_info(opts)
-
-```ruby
-begin
-  # Unavailabilities deleted on one of your cars
-  data, status_code, headers = api_instance.deleted_unavailability_post_with_http_info(opts)
-  p status_code # => 2xx
-  p headers # => { ... }
-  p data # => nil
+  #Find Unavailabilities related to a car between dates
+  result = api_instance.get_unavailabilities_for_car(start_date, end_date, car_id, opts)
+  p result
 rescue GetAroundOwner::ApiError => e
-  puts "Error when calling UnavailabilitiesApi->deleted_unavailability_post_with_http_info: #{e}"
+  puts "Exception when calling UnavailabilitiesApi->get_unavailabilities_for_car: #{e}"
 end
 ```
 
 ### Parameters
 
-| Name | Type | Description | Notes |
-| ---- | ---- | ----------- | ----- |
-| **getaround_unavailabilities_deleted** | [**GetaroundUnavailabilitiesDeleted**](GetaroundUnavailabilitiesDeleted.md) | This event is triggered whenever an unavailability is deleted (through the API or directly in the app/website). It shows the unavailability that has just been deleted, with the same timestamps as those entered by the user. It does not show the changes of other potential overlapping unavailabilities. For example: if an unavailability was already set between June 10 and June 20, and if the user deletes an unavailability between June 18 and June 22 (to set their car as available between this dates), this webhook will only send information about the newly deleted June 18 - June 22 unavailability. It will not show that, under the hood, the unavailability from June 10 to June 20 has be deleted, and that a new unavailability from June 10 to June 18 has been created. | [optional] |
+Name | Type | Description  | Notes
+------------- | ------------- | ------------- | -------------
+ **start_date** | [****](.md)| Start date and time in [ISO8601 format](https://www.iso.org/iso-8601-date-and-time-format.html) | 
+ **end_date** | [****](.md)| End date and time in [ISO8601 format](https://www.iso.org/iso-8601-date-and-time-format.html) | 
+ **car_id** | [****](.md)| ID of the car | 
+ **page** | [****](.md)| Page number | [optional] 
+ **per_page** | [****](.md)| Page size | [optional] [default to 30]
 
 ### Return type
 
-nil (empty response body)
+[**UnavailabilitiesIndex**](UnavailabilitiesIndex.md)
 
 ### Authorization
 
-No authorization required
+[bearerAuth](../README.md#bearerAuth)
 
 ### HTTP request headers
 
-- **Content-Type**: application/json
-- **Accept**: Not defined
+ - **Content-Type**: Not defined
+ - **Accept**: application/json
+
+
 

data/docs/UnavailabilitiesCreated.md

@@ -0,0 +1,6 @@
+# GetAroundOwner::UnavailabilitiesCreated
+
+## Properties
+Name | Type | Description | Notes
+------------ | ------------- | ------------- | -------------
+

data/docs/UnavailabilitiesDeleted.md

@@ -0,0 +1,6 @@
+# GetAroundOwner::UnavailabilitiesDeleted
+
+## Properties
+Name | Type | Description | Notes
+------------ | ------------- | ------------- | -------------
+

data/docs/UnavailabilitiesIndex.md

@@ -0,0 +1,6 @@
+# GetAroundOwner::UnavailabilitiesIndex
+
+## Properties
+Name | Type | Description | Notes
+------------ | ------------- | ------------- | -------------
+

data/docs/Unavailability.md

@@ -0,0 +1,10 @@
+# GetAroundOwner::Unavailability
+
+## Properties
+Name | Type | Description | Notes
+------------ | ------------- | ------------- | -------------
+**car_id** | [****](.md) | ID of the related car | 
+**starts_at** | [****](.md) | The ISO8601 formatted beginning of the unavailability's period | 
+**ends_at** | [****](.md) | The ISO8601 formatted ending of the unavailability's period | 
+**reason** | [****](.md) | The reason of the unavailability of the car. | [optional] 
+

data/docs/User.md

@@ -0,0 +1,19 @@
+# GetAroundOwner::User
+
+## Properties
+Name | Type | Description | Notes
+------------ | ------------- | ------------- | -------------
+**id** | [****](.md) | The user ID | 
+**first_name** | [****](.md) | First name(s) | 
+**last_name** | [****](.md) | Last name(s) | 
+**phone_number** | [****](.md) | The phone number in international format | 
+**address_line1** | [****](.md) | Residential address of the user | 
+**address_line2** | [****](.md) | Additional address details | [optional] 
+**postal_code** | [****](.md) | The postal code | 
+**city** | [****](.md) | The city | 
+**country** | [****](.md) | Address's country format ISO_3166-1_alpha-2 (ex: FR, ES, ...) | 
+**birth_date** | [****](.md) | The birth date | 
+**license_country** | [****](.md) | Driving licence country of issue format ISO_3166-1_alpha-2 (ex: FR, ES, ...) | 
+**license_first_issue_date** | [****](.md) | Driving licence first issue date | 
+**license_number** | [****](.md) | The license number | 
+

data/docs/UsersApi.md

@@ -2,70 +2,56 @@
 
 All URIs are relative to *https://api-eu.getaround.com/owner/v1*
 
-| Method | HTTP request | Description |
-| ------ | ------------ | ----------- |
-| [**updated_user_post**](UsersApi.md#updated_user_post) | **POST** /updatedUser | User updated his profile information |
+Method | HTTP request | Description
+------------- | ------------- | -------------
+[**get_user_by_id**](UsersApi.md#get_user_by_id) | **GET** /users/{id}.json | Find a user by ID (Users are customers who rent one of your cars)
 
+# **get_user_by_id**
+> User get_user_by_id(id)
 
-## updated_user_post
+Find a user by ID (Users are customers who rent one of your cars)
 
-> updated_user_post(opts)
-
-User updated his profile information
-
-### Examples
+Find a user by ID (Users are customers who rent one of your cars)
 
+### Example
 ```ruby
-require 'time'
-require 'get_around_owner'
-
-api_instance = GetAroundOwner::UsersApi.new
-opts = {
-  getaround_users_updated:  # GetaroundUsersUpdated | This event is triggered when a user updates his profile information (You will only receive this event on users with a booked rental or a started rental).
-}
-
-begin
-  # User updated his profile information
-  api_instance.updated_user_post(opts)
-rescue GetAroundOwner::ApiError => e
-  puts "Error when calling UsersApi->updated_user_post: #{e}"
+# load the gem
+require 'getaround-api'
+# setup authorization
+GetAroundOwner.configure do |config|
 end
-```
-
-#### Using the updated_user_post_with_http_info variant
 
-This returns an Array which contains the response data (`nil` in this case), status code and headers.
+api_instance = GetAroundOwner::UsersApi.new
+id = GetAroundOwner::null.new #  | ID of user to return
 
-> <Array(nil, Integer, Hash)> updated_user_post_with_http_info(opts)
 
-```ruby
 begin
-  # User updated his profile information
-  data, status_code, headers = api_instance.updated_user_post_with_http_info(opts)
-  p status_code # => 2xx
-  p headers # => { ... }
-  p data # => nil
+  #Find a user by ID (Users are customers who rent one of your cars)
+  result = api_instance.get_user_by_id(id)
+  p result
 rescue GetAroundOwner::ApiError => e
-  puts "Error when calling UsersApi->updated_user_post_with_http_info: #{e}"
+  puts "Exception when calling UsersApi->get_user_by_id: #{e}"
 end
 ```
 
 ### Parameters
 
-| Name | Type | Description | Notes |
-| ---- | ---- | ----------- | ----- |
-| **getaround_users_updated** | [**GetaroundUsersUpdated**](GetaroundUsersUpdated.md) | This event is triggered when a user updates his profile information (You will only receive this event on users with a booked rental or a started rental). | [optional] |
+Name | Type | Description  | Notes
+------------- | ------------- | ------------- | -------------
+ **id** | [****](.md)| ID of user to return | 
 
 ### Return type
 
-nil (empty response body)
+[**User**](User.md)
 
 ### Authorization
 
-No authorization required
+[bearerAuth](../README.md#bearerAuth)
 
 ### HTTP request headers
 
-- **Content-Type**: application/json
-- **Accept**: Not defined
+ - **Content-Type**: Not defined
+ - **Accept**: application/json
+
+
 

data/docs/UsersUpdated.md

@@ -0,0 +1,6 @@
+# GetAroundOwner::UsersUpdated
+
+## Properties
+Name | Type | Description | Notes
+------------ | ------------- | ------------- | -------------
+

data/docs/Webhook.md

@@ -0,0 +1,9 @@
+# GetAroundOwner::Webhook
+
+## Properties
+Name | Type | Description | Notes
+------------ | ------------- | ------------- | -------------
+**type** | [****](.md) | The webhook event type | 
+**data** | [****](.md) | The webhook event data | 
+**occurred_at** | [****](.md) | The webhook event occurred at timestamp | 
+

data/get_around_owner.gemspec

@@ -1,16 +1,29 @@
 # -*- encoding: utf-8 -*-
 
+=begin
+#Getaround Owner API
+
+## Quick Start  The Owner API uses the JSON format, and must be accessed over a [secure connection](https://en.wikipedia.org/wiki/HTTPS).  Let’s assume that the access token provided by your account manager is “TOKEN”.  Here’s how to get the list of ids of all your invoices from the first week of August with a shell script:  ```bash query=\"end_date=2018-08-08T00%3A00%3A00%2B00%3A00&start_date=2018-08-01T00%3A00%3A00%2B00%3A00\"  curl -i \"https://api-eu.getaround.com/owner/v1/invoices?${query}\" \\   -H \"Authorization: Bearer TOKEN\" \\   -H \"Accept:application/json\" \\   -H \"Content-Type:application/json\" ```  And here’s how to get the invoice with the id 12345:  ```bash curl -i \"https://api-eu.getaround.com/owner/v1/invoices/12345\" \\   -H \"Authorization: Bearer TOKEN\" \\   -H \"Accept: application/json\" \\   -H \"Content-Type: application/json\"\" ```  See the [endpoints section](#tag/Invoices) of this guide for details about the response format.  Dates in request params should follow the ISO 8601 standard.   # Authentication  All requests must be authenticated with a [bearer token header](https://tools.ietf.org/html/rfc6750#section-2.1). You token will be sent to you by your account manager.  Unauthenticated requests will return a 401 status.   # Pagination  The page number and the number of items per page can be set with the “page” and “per_page” params.  For example, this request will return the second page of invoices, and 50 invoices per page:  `https://api-eu.getaround.com/owner/v1/invoices?page=2&per_page=50`  Both of these params are optional. The default page size is 30 items.  The Getaround Owner API follows the [RFC 8288 convention](https://datatracker.ietf.org/doc/html/rfc8288) of using the `Link` header to provide the `next` page URL. Please don't build the pagination URLs yourself. The `next` page will be missing when you are requesting the last available page.  Here's an example response header from requesting the second page of invoices `https://api-eu.getaround.com/owner/v1/invoices?page=2&per_page=50` ``` Link: <https://api-eu.getaround.com/owner/v1/invoices?page=3&per_page=50>; rel=\"next\" ```   # Throttling policy and Date range limitation  We have throttling policy that prevents you to perform more than 100 requests per min from the same IP.  Also, there is a limitation on the size of the range of dates given in params in some requests.  All requests that need start_date and end_date, do not accept a range bigger than 30 days.   # Webhooks  Getaround can send webhook events that notify your application when certain events happen on your account. This is especially useful to follow the lifecycle of rentals, tracking for example bookings or cancellations.  ### Setup  To set up an endpoint, you need to define a route on your server for receiving events, and then <a href=\"mailto:owner-api@getaround.com\">ask Getaround</a> to add this URL to your account.  To acknowledge receipt of a event, your endpoint must:  - Return a `2xx` HTTP status code. - Be a secure `https` endpoint with a valid SSL certificate.  ### Testing  Once Getaround has set up the endpoint, and it is properly configured as described above, a test `ping` event can be sent by clicking the button below:  <form action=\"/docs/api/owner/fire_ping_webhook\" method=\"post\"><input type=\"submit\" value=\"Send Ping Event\"></form>  You should receive the following JSON payload:  ```json {   \"data\": {     \"ping\": \"pong\"   },   \"type\": \"ping\",   \"occurred_at\": \"2019-04-18T08:30:05Z\" } ```  ### Retries  Webhook deliveries will be attempted for up to three days with an exponential back off. After that point the delivery will be abandoned.  ### Verifying Signatures  Getaround will also provide you with a secret token, which is used to create a hash signature with each payload.  This hash signature is passed along with each request in the headers as `X-Drivy-Signature`. Suppose you have a basic server listening to webhooks that looks like this:  ```ruby require 'sinatra' require 'json'  post '/payload' do   push = JSON.parse(params[:payload])   \"I got some JSON: \#{push.inspect}\" end ```  The goal is to compute a hash using your secret token, and ensure that the hash from Getaround matches. Getaround uses an HMAC hexdigest to compute the hash, so you could change your server to look a little like this:  ```ruby post '/payload' do   request.body.rewind   payload_body = request.body.read   verify_signature(payload_body)   push = JSON.parse(params[:payload])   \"I got some JSON: \#{push.inspect}\" end  def verify_signature(payload_body)   signature = 'sha1=' + OpenSSL::HMAC.hexdigest(OpenSSL::Digest.new('sha1'), ENV['SECRET_TOKEN'], payload_body)   return halt 500, \"Signatures didn't match!\" unless Rack::Utils.secure_compare(signature, request.env['HTTP_X_DRIVY_SIGNATURE']) end ```  Obviously, your language and server implementations may differ from this code. There are a couple of important things to point out, however:  No matter which implementation you use, the hash signature starts with `sha1=`, using the key of your secret token and your payload body.  Using a plain `==` operator is not advised. A method like secure_compare performs a \"constant time\" string comparison, which renders it safe from certain timing attacks against regular equality operators.  ### Best Practices  - **Acknowledge events immediately**. If your webhook script performs complex logic, or makes network calls, it’s possible that the script would time out before Getaround sees its complete execution. Ideally, your webhook handler code (acknowledging receipt of an event by returning a `2xx` status code) is separate of any other logic you do for that event. - **Handle duplicate events**. Webhook endpoints might occasionally receive the same event more than once. We advise you to guard against duplicated event receipts by making your event processing idempotent. One way of doing this is logging the events you’ve processed, and then not processing already-logged events. - **Do not expect events in order**. Getaround does not guarantee delivery of events in the order in which they are generated. Your endpoint should therefore handle this accordingly. We do provide an `occurred_at` timestamp for each event, though, to help reconcile ordering.
+
+The version of the OpenAPI document: 1.0.0
+Contact: owner-api@getaround.com
+Generated by: https://openapi-generator.tech
+Generator version: 7.10.0
+
+=end
+
 $:.push File.expand_path("../lib", __FILE__)
-require "get_around_owner/version"
+require "getaround-api/version"
 
 Gem::Specification.new do |s|
   s.name        = "get_around_owner"
   s.version     = GetAroundOwner::VERSION
   s.platform    = Gem::Platform::RUBY
-  s.authors     = ["OpenAPI-Generator", "yann120"]
+  s.authors     = ["OpenAPI-Generator"]
+  s.email       = ["owner-api@getaround.com"]
   s.homepage    = "https://openapi-generator.tech"
   s.summary     = "Getaround Owner API Ruby Gem"
-  s.description = "Getaround Owner API Wrapper"
+  s.description = "# Quick Start  The Owner API uses the JSON format, and must be accessed over a [secure connection](https://en.wikipedia.org/wiki/HTTPS).  Let’s assume that the access token provided by your account manager is “TOKEN”.  Here’s how to get the list of ids of all your invoices from the first week of August with a shell script:  ```bash query=\"end_date=2018-08-08T00%3A00%3A00%2B00%3A00&start_date=2018-08-01T00%3A00%3A00%2B00%3A00\"  curl -i \"https://api-eu.getaround.com/owner/v1/invoices?${query}\" \\   -H \"Authorization: Bearer TOKEN\" \\   -H \"Accept:application/json\" \\   -H \"Content-Type:application/json\" ```  And here’s how to get the invoice with the id 12345:  ```bash curl -i \"https://api-eu.getaround.com/owner/v1/invoices/12345\" \\   -H \"Authorization: Bearer TOKEN\" \\   -H \"Accept: application/json\" \\   -H \"Content-Type: application/json\"\" ```  See the [endpoints section](#tag/Invoices) of this guide for details about the response format.  Dates in request params should follow the ISO 8601 standard.   # Authentication  All requests must be authenticated with a [bearer token header](https://tools.ietf.org/html/rfc6750#section-2.1). You token will be sent to you by your account manager.  Unauthenticated requests will return a 401 status.   # Pagination  The page number and the number of items per page can be set with the “page” and “per_page” params.  For example, this request will return the second page of invoices, and 50 invoices per page:  `https://api-eu.getaround.com/owner/v1/invoices?page=2&per_page=50`  Both of these params are optional. The default page size is 30 items.  The Getaround Owner API follows the [RFC 8288 convention](https://datatracker.ietf.org/doc/html/rfc8288) of using the `Link` header to provide the `next` page URL. Please don't build the pagination URLs yourself. The `next` page will be missing when you are requesting the last available page.  Here's an example response header from requesting the second page of invoices `https://api-eu.getaround.com/owner/v1/invoices?page=2&per_page=50` ``` Link: <https://api-eu.getaround.com/owner/v1/invoices?page=3&per_page=50>; rel=\"next\" ```   # Throttling policy and Date range limitation  We have throttling policy that prevents you to perform more than 100 requests per min from the same IP.  Also, there is a limitation on the size of the range of dates given in params in some requests.  All requests that need start_date and end_date, do not accept a range bigger than 30 days.   # Webhooks  Getaround can send webhook events that notify your application when certain events happen on your account. This is especially useful to follow the lifecycle of rentals, tracking for example bookings or cancellations.  ### Setup  To set up an endpoint, you need to define a route on your server for receiving events, and then <a href=\"mailto:owner-api@getaround.com\">ask Getaround</a> to add this URL to your account.  To acknowledge receipt of a event, your endpoint must:  - Return a `2xx` HTTP status code. - Be a secure `https` endpoint with a valid SSL certificate.  ### Testing  Once Getaround has set up the endpoint, and it is properly configured as described above, a test `ping` event can be sent by clicking the button below:  <form action=\"/docs/api/owner/fire_ping_webhook\" method=\"post\"><input type=\"submit\" value=\"Send Ping Event\"></form>  You should receive the following JSON payload:  ```json {   \"data\": {     \"ping\": \"pong\"   },   \"type\": \"ping\",   \"occurred_at\": \"2019-04-18T08:30:05Z\" } ```  ### Retries  Webhook deliveries will be attempted for up to three days with an exponential back off. After that point the delivery will be abandoned.  ### Verifying Signatures  Getaround will also provide you with a secret token, which is used to create a hash signature with each payload.  This hash signature is passed along with each request in the headers as `X-Drivy-Signature`. Suppose you have a basic server listening to webhooks that looks like this:  ```ruby require 'sinatra' require 'json'  post '/payload' do   push = JSON.parse(params[:payload])   \"I got some JSON: \#{push.inspect}\" end ```  The goal is to compute a hash using your secret token, and ensure that the hash from Getaround matches. Getaround uses an HMAC hexdigest to compute the hash, so you could change your server to look a little like this:  ```ruby post '/payload' do   request.body.rewind   payload_body = request.body.read   verify_signature(payload_body)   push = JSON.parse(params[:payload])   \"I got some JSON: \#{push.inspect}\" end  def verify_signature(payload_body)   signature = 'sha1=' + OpenSSL::HMAC.hexdigest(OpenSSL::Digest.new('sha1'), ENV['SECRET_TOKEN'], payload_body)   return halt 500, \"Signatures didn't match!\" unless Rack::Utils.secure_compare(signature, request.env['HTTP_X_DRIVY_SIGNATURE']) end ```  Obviously, your language and server implementations may differ from this code. There are a couple of important things to point out, however:  No matter which implementation you use, the hash signature starts with `sha1=`, using the key of your secret token and your payload body.  Using a plain `==` operator is not advised. A method like secure_compare performs a \"constant time\" string comparison, which renders it safe from certain timing attacks against regular equality operators.  ### Best Practices  - **Acknowledge events immediately**. If your webhook script performs complex logic, or makes network calls, it’s possible that the script would time out before Getaround sees its complete execution. Ideally, your webhook handler code (acknowledging receipt of an event by returning a `2xx` status code) is separate of any other logic you do for that event. - **Handle duplicate events**. Webhook endpoints might occasionally receive the same event more than once. We advise you to guard against duplicated event receipts by making your event processing idempotent. One way of doing this is logging the events you’ve processed, and then not processing already-logged events. - **Do not expect events in order**. Getaround does not guarantee delivery of events in the order in which they are generated. Your endpoint should therefore handle this accordingly. We do provide an `occurred_at` timestamp for each event, though, to help reconcile ordering. "
   s.license     = "Unlicense"
   s.required_ruby_version = ">= 2.7"
   s.metadata    = {}

data/getaround-api.gemspec

@@ -0,0 +1,38 @@
+# -*- encoding: utf-8 -*-
+
+=begin
+#Getaround Owner API
+
+## Quick Start  The Owner API uses the JSON format, and must be accessed over a [secure connection](https://en.wikipedia.org/wiki/HTTPS).  Let’s assume that the access token provided by your account manager is “TOKEN”.  Here’s how to get the list of ids of all your invoices from the first week of August with a shell script:  ```bash query=\"end_date=2018-08-08T00%3A00%3A00%2B00%3A00&start_date=2018-08-01T00%3A00%3A00%2B00%3A00\"  curl -i \"https://api-eu.getaround.com/owner/v1/invoices?${query}\" \\   -H \"Authorization: Bearer TOKEN\" \\   -H \"Accept:application/json\" \\   -H \"Content-Type:application/json\" ```  And here’s how to get the invoice with the id 12345:  ```bash curl -i \"https://api-eu.getaround.com/owner/v1/invoices/12345\" \\   -H \"Authorization: Bearer TOKEN\" \\   -H \"Accept: application/json\" \\   -H \"Content-Type: application/json\"\" ```  See the [endpoints section](#tag/Invoices) of this guide for details about the response format.  Dates in request params should follow the ISO 8601 standard.   # Authentication  All requests must be authenticated with a [bearer token header](https://tools.ietf.org/html/rfc6750#section-2.1). You token will be sent to you by your account manager.  Unauthenticated requests will return a 401 status.   # Pagination  The page number and the number of items per page can be set with the “page” and “per_page” params.  For example, this request will return the second page of invoices, and 50 invoices per page:  `https://api-eu.getaround.com/owner/v1/invoices?page=2&per_page=50`  Both of these params are optional. The default page size is 30 items.  The Getaround Owner API follows the [RFC 8288 convention](https://datatracker.ietf.org/doc/html/rfc8288) of using the `Link` header to provide the `next` page URL. Please don't build the pagination URLs yourself. The `next` page will be missing when you are requesting the last available page.  Here's an example response header from requesting the second page of invoices `https://api-eu.getaround.com/owner/v1/invoices?page=2&per_page=50` ``` Link: <https://api-eu.getaround.com/owner/v1/invoices?page=3&per_page=50>; rel=\"next\" ```   # Throttling policy and Date range limitation  We have throttling policy that prevents you to perform more than 100 requests per min from the same IP.  Also, there is a limitation on the size of the range of dates given in params in some requests.  All requests that need start_date and end_date, do not accept a range bigger than 30 days.   # Webhooks  Getaround can send webhook events that notify your application when certain events happen on your account. This is especially useful to follow the lifecycle of rentals, tracking for example bookings or cancellations.  ### Setup  To set up an endpoint, you need to define a route on your server for receiving events, and then <a href=\"mailto:owner-api@getaround.com\">ask Getaround</a> to add this URL to your account.  To acknowledge receipt of a event, your endpoint must:  - Return a `2xx` HTTP status code. - Be a secure `https` endpoint with a valid SSL certificate.  ### Testing  Once Getaround has set up the endpoint, and it is properly configured as described above, a test `ping` event can be sent by clicking the button below:  <form action=\"/docs/api/owner/fire_ping_webhook\" method=\"post\"><input type=\"submit\" value=\"Send Ping Event\"></form>  You should receive the following JSON payload:  ```json {   \"data\": {     \"ping\": \"pong\"   },   \"type\": \"ping\",   \"occurred_at\": \"2019-04-18T08:30:05Z\" } ```  ### Retries  Webhook deliveries will be attempted for up to three days with an exponential back off. After that point the delivery will be abandoned.  ### Verifying Signatures  Getaround will also provide you with a secret token, which is used to create a hash signature with each payload.  This hash signature is passed along with each request in the headers as `X-Drivy-Signature`. Suppose you have a basic server listening to webhooks that looks like this:  ```ruby require 'sinatra' require 'json'  post '/payload' do   push = JSON.parse(params[:payload])   \"I got some JSON: #{push.inspect}\" end ```  The goal is to compute a hash using your secret token, and ensure that the hash from Getaround matches. Getaround uses an HMAC hexdigest to compute the hash, so you could change your server to look a little like this:  ```ruby post '/payload' do   request.body.rewind   payload_body = request.body.read   verify_signature(payload_body)   push = JSON.parse(params[:payload])   \"I got some JSON: #{push.inspect}\" end  def verify_signature(payload_body)   signature = 'sha1=' + OpenSSL::HMAC.hexdigest(OpenSSL::Digest.new('sha1'), ENV['SECRET_TOKEN'], payload_body)   return halt 500, \"Signatures didn't match!\" unless Rack::Utils.secure_compare(signature, request.env['HTTP_X_DRIVY_SIGNATURE']) end ```  Obviously, your language and server implementations may differ from this code. There are a couple of important things to point out, however:  No matter which implementation you use, the hash signature starts with `sha1=`, using the key of your secret token and your payload body.  Using a plain `==` operator is not advised. A method like secure_compare performs a \"constant time\" string comparison, which renders it safe from certain timing attacks against regular equality operators.  ### Best Practices  - **Acknowledge events immediately**. If your webhook script performs complex logic, or makes network calls, it’s possible that the script would time out before Getaround sees its complete execution. Ideally, your webhook handler code (acknowledging receipt of an event by returning a `2xx` status code) is separate of any other logic you do for that event. - **Handle duplicate events**. Webhook endpoints might occasionally receive the same event more than once. We advise you to guard against duplicated event receipts by making your event processing idempotent. One way of doing this is logging the events you’ve processed, and then not processing already-logged events. - **Do not expect events in order**. Getaround does not guarantee delivery of events in the order in which they are generated. Your endpoint should therefore handle this accordingly. We do provide an `occurred_at` timestamp for each event, though, to help reconcile ordering. 
+
+OpenAPI spec version: 1.0.0
+Contact: owner-api@getaround.com
+Generated by: https://github.com/swagger-api/swagger-codegen.git
+Swagger Codegen version: 3.0.66
+=end
+
+$:.push File.expand_path("../lib", __FILE__)
+require "getaround-api/version"
+
+Gem::Specification.new do |s|
+  s.name        = "getaround-api"
+  s.version     = GetAroundOwner::VERSION
+  s.platform    = Gem::Platform::RUBY
+  s.authors     = ["YannPETITJEAN"]
+  s.email       = ["owner-api@getaround.com"]
+  s.homepage    = "https://github.com/swagger-api/swagger-codegen"
+  s.summary     = "Getaround Owner API Ruby Gem"
+  s.description = "# Quick Start  The Owner API uses the JSON format, and must be accessed over a [secure connection](https://en.wikipedia.org/wiki/HTTPS).  Let’s assume that the access token provided by your account manager is “TOKEN”.  Here’s how to get the list of ids of all your invoices from the first week of August with a shell script:  ```bash query=\"end_date=2018-08-08T00%3A00%3A00%2B00%3A00&start_date=2018-08-01T00%3A00%3A00%2B00%3A00\"  curl -i \"https://api-eu.getaround.com/owner/v1/invoices?${query}\" \\   -H \"Authorization: Bearer TOKEN\" \\   -H \"Accept:application/json\" \\   -H \"Content-Type:application/json\" ```  And here’s how to get the invoice with the id 12345:  ```bash curl -i \"https://api-eu.getaround.com/owner/v1/invoices/12345\" \\   -H \"Authorization: Bearer TOKEN\" \\   -H \"Accept: application/json\" \\   -H \"Content-Type: application/json\"\" ```  See the [endpoints section](#tag/Invoices) of this guide for details about the response format.  Dates in request params should follow the ISO 8601 standard.   # Authentication  All requests must be authenticated with a [bearer token header](https://tools.ietf.org/html/rfc6750#section-2.1). You token will be sent to you by your account manager.  Unauthenticated requests will return a 401 status.   # Pagination  The page number and the number of items per page can be set with the “page” and “per_page” params.  For example, this request will return the second page of invoices, and 50 invoices per page:  `https://api-eu.getaround.com/owner/v1/invoices?page=2&per_page=50`  Both of these params are optional. The default page size is 30 items.  The Getaround Owner API follows the [RFC 8288 convention](https://datatracker.ietf.org/doc/html/rfc8288) of using the `Link` header to provide the `next` page URL. Please don't build the pagination URLs yourself. The `next` page will be missing when you are requesting the last available page.  Here's an example response header from requesting the second page of invoices `https://api-eu.getaround.com/owner/v1/invoices?page=2&per_page=50` ``` Link: <https://api-eu.getaround.com/owner/v1/invoices?page=3&per_page=50>; rel=\"next\" ```   # Throttling policy and Date range limitation  We have throttling policy that prevents you to perform more than 100 requests per min from the same IP.  Also, there is a limitation on the size of the range of dates given in params in some requests.  All requests that need start_date and end_date, do not accept a range bigger than 30 days.   # Webhooks  Getaround can send webhook events that notify your application when certain events happen on your account. This is especially useful to follow the lifecycle of rentals, tracking for example bookings or cancellations.  ### Setup  To set up an endpoint, you need to define a route on your server for receiving events, and then <a href=\"mailto:owner-api@getaround.com\">ask Getaround</a> to add this URL to your account.  To acknowledge receipt of a event, your endpoint must:  - Return a `2xx` HTTP status code. - Be a secure `https` endpoint with a valid SSL certificate.  ### Testing  Once Getaround has set up the endpoint, and it is properly configured as described above, a test `ping` event can be sent by clicking the button below:  <form action=\"/docs/api/owner/fire_ping_webhook\" method=\"post\"><input type=\"submit\" value=\"Send Ping Event\"></form>  You should receive the following JSON payload:  ```json {   \"data\": {     \"ping\": \"pong\"   },   \"type\": \"ping\",   \"occurred_at\": \"2019-04-18T08:30:05Z\" } ```  ### Retries  Webhook deliveries will be attempted for up to three days with an exponential back off. After that point the delivery will be abandoned.  ### Verifying Signatures  Getaround will also provide you with a secret token, which is used to create a hash signature with each payload.  This hash signature is passed along with each request in the headers as `X-Drivy-Signature`. Suppose you have a basic server listening to webhooks that looks like this:  ```ruby require 'sinatra' require 'json'  post '/payload' do   push = JSON.parse(params[:payload])   \"I got some JSON: #{push.inspect}\" end ```  The goal is to compute a hash using your secret token, and ensure that the hash from Getaround matches. Getaround uses an HMAC hexdigest to compute the hash, so you could change your server to look a little like this:  ```ruby post '/payload' do   request.body.rewind   payload_body = request.body.read   verify_signature(payload_body)   push = JSON.parse(params[:payload])   \"I got some JSON: #{push.inspect}\" end  def verify_signature(payload_body)   signature = 'sha1=' + OpenSSL::HMAC.hexdigest(OpenSSL::Digest.new('sha1'), ENV['SECRET_TOKEN'], payload_body)   return halt 500, \"Signatures didn't match!\" unless Rack::Utils.secure_compare(signature, request.env['HTTP_X_DRIVY_SIGNATURE']) end ```  Obviously, your language and server implementations may differ from this code. There are a couple of important things to point out, however:  No matter which implementation you use, the hash signature starts with `sha1=`, using the key of your secret token and your payload body.  Using a plain `==` operator is not advised. A method like secure_compare performs a \"constant time\" string comparison, which renders it safe from certain timing attacks against regular equality operators.  ### Best Practices  - **Acknowledge events immediately**. If your webhook script performs complex logic, or makes network calls, it’s possible that the script would time out before Getaround sees its complete execution. Ideally, your webhook handler code (acknowledging receipt of an event by returning a `2xx` status code) is separate of any other logic you do for that event. - **Handle duplicate events**. Webhook endpoints might occasionally receive the same event more than once. We advise you to guard against duplicated event receipts by making your event processing idempotent. One way of doing this is logging the events you’ve processed, and then not processing already-logged events. - **Do not expect events in order**. Getaround does not guarantee delivery of events in the order in which they are generated. Your endpoint should therefore handle this accordingly. We do provide an `occurred_at` timestamp for each event, though, to help reconcile ordering. "
+  s.license     = "Unlicense"
+  s.required_ruby_version = ">= 1.9"
+
+  s.add_runtime_dependency 'typhoeus', '~> 1.0', '>= 1.0.1'
+  s.add_runtime_dependency 'json', '~> 2.1', '>= 2.1.0'
+
+  s.add_development_dependency 'rspec', '~> 3.6', '>= 3.6.0'
+
+  s.files         = `find *`.split("\n").uniq.sort.select { |f| !f.empty? }
+  s.test_files    = `find spec/*`.split("\n")
+  s.executables   = []
+  s.require_paths = ["lib"]
+end

data/git_push.sh

@@ -1,17 +1,14 @@
 #!/bin/sh
+#
+# Generated by: https://github.com/swagger-api/swagger-codegen.git
+#
 # ref: https://help.github.com/articles/adding-an-existing-project-to-github-using-the-command-line/
 #
-# Usage example: /bin/sh ./git_push.sh wing328 openapi-petstore-perl "minor update" "gitlab.com"
+# Usage example: /bin/sh ./git_push.sh wing328 swagger-petstore-perl "minor update"
 
 git_user_id=$1
 git_repo_id=$2
 release_note=$3
-git_host=$4
-
-if [ "$git_host" = "" ]; then
-    git_host="github.com"
-    echo "[INFO] No command line input provided. Set \$git_host to $git_host"
-fi
 
 if [ "$git_user_id" = "" ]; then
     git_user_id="GIT_USER_ID"
@@ -38,14 +35,14 @@ git add .
 git commit -m "$release_note"
 
 # Sets the new remote
-git_remote=$(git remote)
+git_remote=`git remote`
 if [ "$git_remote" = "" ]; then # git remote not defined
 
     if [ "$GIT_TOKEN" = "" ]; then
         echo "[INFO] \$GIT_TOKEN (environment variable) is not set. Using the git credential in your environment."
-        git remote add origin https://${git_host}/${git_user_id}/${git_repo_id}.git
+        git remote add origin https://github.com/${git_user_id}/${git_repo_id}.git
     else
-        git remote add origin https://${git_user_id}:"${GIT_TOKEN}"@${git_host}/${git_user_id}/${git_repo_id}.git
+        git remote add origin https://${git_user_id}:${GIT_TOKEN}@github.com/${git_user_id}/${git_repo_id}.git
     fi
 
 fi
@@ -53,5 +50,6 @@ fi
 git pull origin master
 
 # Pushes (Forces) the changes in the local repository up to the remote repository
-echo "Git pushing to https://${git_host}/${git_user_id}/${git_repo_id}.git"
+echo "Git pushing to https://github.com/${git_user_id}/${git_repo_id}.git"
 git push origin master 2>&1 | grep -v 'To https'
+