get_around_owner 1.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (154) hide show
  1. checksums.yaml +7 -0
  2. data/Gemfile +9 -0
  3. data/README.md +303 -0
  4. data/Rakefile +10 -0
  5. data/docs/CarsApi.md +151 -0
  6. data/docs/CheckinsApi.md +71 -0
  7. data/docs/CheckoutsApi.md +71 -0
  8. data/docs/GetaroundCar.md +28 -0
  9. data/docs/GetaroundCarsIndexInner.md +18 -0
  10. data/docs/GetaroundCheckin.md +24 -0
  11. data/docs/GetaroundCheckinsIndexInner.md +18 -0
  12. data/docs/GetaroundCheckout.md +26 -0
  13. data/docs/GetaroundCreateMessagesRequest.md +18 -0
  14. data/docs/GetaroundCreateUnavailabilitiesRequest.md +22 -0
  15. data/docs/GetaroundDestroyUnavailabilityRequest.md +20 -0
  16. data/docs/GetaroundInvoice.md +34 -0
  17. data/docs/GetaroundInvoiceChargesInner.md +20 -0
  18. data/docs/GetaroundInvoicesIndexInner.md +18 -0
  19. data/docs/GetaroundMessage.md +26 -0
  20. data/docs/GetaroundMessagesSent.md +22 -0
  21. data/docs/GetaroundMessagesSentAllOfData.md +20 -0
  22. data/docs/GetaroundPayout.md +28 -0
  23. data/docs/GetaroundPayoutInvoicesInner.md +18 -0
  24. data/docs/GetaroundPayoutsIndexInner.md +18 -0
  25. data/docs/GetaroundReason.md +15 -0
  26. data/docs/GetaroundRental.md +32 -0
  27. data/docs/GetaroundRentalInvoicesIndexInner.md +18 -0
  28. data/docs/GetaroundRentalMessagesIndexInner.md +18 -0
  29. data/docs/GetaroundRentalsBooked.md +22 -0
  30. data/docs/GetaroundRentalsBookedAllOfData.md +18 -0
  31. data/docs/GetaroundRentalsCanceled.md +22 -0
  32. data/docs/GetaroundRentalsCarCheckedIn.md +22 -0
  33. data/docs/GetaroundRentalsCarCheckedOut.md +22 -0
  34. data/docs/GetaroundRentalsCarSwitched.md +22 -0
  35. data/docs/GetaroundRentalsIndexInner.md +18 -0
  36. data/docs/GetaroundRentalsTimesChanged.md +22 -0
  37. data/docs/GetaroundUnavailabilitiesCreated.md +22 -0
  38. data/docs/GetaroundUnavailabilitiesCreatedAllOfData.md +24 -0
  39. data/docs/GetaroundUnavailabilitiesDeleted.md +22 -0
  40. data/docs/GetaroundUnavailabilitiesDeletedAllOfData.md +22 -0
  41. data/docs/GetaroundUnavailability.md +24 -0
  42. data/docs/GetaroundUser.md +42 -0
  43. data/docs/GetaroundUsersUpdated.md +22 -0
  44. data/docs/GetaroundUsersUpdatedAllOfData.md +18 -0
  45. data/docs/GetaroundWebhook.md +22 -0
  46. data/docs/InvoicesApi.md +231 -0
  47. data/docs/MessagesApi.md +71 -0
  48. data/docs/PayoutsApi.md +155 -0
  49. data/docs/RentalsApi.md +263 -0
  50. data/docs/UnavailabilitiesApi.md +135 -0
  51. data/docs/UsersApi.md +71 -0
  52. data/get_around_owner.gemspec +26 -0
  53. data/git_push.sh +57 -0
  54. data/lib/get_around_owner/api/cars_api.rb +148 -0
  55. data/lib/get_around_owner/api/checkins_api.rb +82 -0
  56. data/lib/get_around_owner/api/checkouts_api.rb +82 -0
  57. data/lib/get_around_owner/api/invoices_api.rb +223 -0
  58. data/lib/get_around_owner/api/messages_api.rb +82 -0
  59. data/lib/get_around_owner/api/payouts_api.rb +162 -0
  60. data/lib/get_around_owner/api/rentals_api.rb +262 -0
  61. data/lib/get_around_owner/api/unavailabilities_api.rb +142 -0
  62. data/lib/get_around_owner/api/users_api.rb +82 -0
  63. data/lib/get_around_owner/api_client.rb +394 -0
  64. data/lib/get_around_owner/api_error.rb +58 -0
  65. data/lib/get_around_owner/configuration.rb +298 -0
  66. data/lib/get_around_owner/models/getaround_car.rb +308 -0
  67. data/lib/get_around_owner/models/getaround_cars_index_inner.rb +223 -0
  68. data/lib/get_around_owner/models/getaround_checkin.rb +279 -0
  69. data/lib/get_around_owner/models/getaround_checkins_index_inner.rb +222 -0
  70. data/lib/get_around_owner/models/getaround_checkout.rb +298 -0
  71. data/lib/get_around_owner/models/getaround_create_messages_request.rb +222 -0
  72. data/lib/get_around_owner/models/getaround_create_unavailabilities_request.rb +283 -0
  73. data/lib/get_around_owner/models/getaround_destroy_unavailability_request.rb +239 -0
  74. data/lib/get_around_owner/models/getaround_invoice.rb +396 -0
  75. data/lib/get_around_owner/models/getaround_invoice_charges_inner.rb +225 -0
  76. data/lib/get_around_owner/models/getaround_invoices_index_inner.rb +223 -0
  77. data/lib/get_around_owner/models/getaround_message.rb +291 -0
  78. data/lib/get_around_owner/models/getaround_messages_sent.rb +257 -0
  79. data/lib/get_around_owner/models/getaround_messages_sent_all_of_data.rb +225 -0
  80. data/lib/get_around_owner/models/getaround_payout.rb +347 -0
  81. data/lib/get_around_owner/models/getaround_payout_invoices_inner.rb +223 -0
  82. data/lib/get_around_owner/models/getaround_payouts_index_inner.rb +223 -0
  83. data/lib/get_around_owner/models/getaround_reason.rb +45 -0
  84. data/lib/get_around_owner/models/getaround_rental.rb +380 -0
  85. data/lib/get_around_owner/models/getaround_rental_invoices_index_inner.rb +223 -0
  86. data/lib/get_around_owner/models/getaround_rental_messages_index_inner.rb +223 -0
  87. data/lib/get_around_owner/models/getaround_rentals_booked.rb +257 -0
  88. data/lib/get_around_owner/models/getaround_rentals_booked_all_of_data.rb +215 -0
  89. data/lib/get_around_owner/models/getaround_rentals_canceled.rb +257 -0
  90. data/lib/get_around_owner/models/getaround_rentals_car_checked_in.rb +257 -0
  91. data/lib/get_around_owner/models/getaround_rentals_car_checked_out.rb +257 -0
  92. data/lib/get_around_owner/models/getaround_rentals_car_switched.rb +257 -0
  93. data/lib/get_around_owner/models/getaround_rentals_index_inner.rb +223 -0
  94. data/lib/get_around_owner/models/getaround_rentals_times_changed.rb +257 -0
  95. data/lib/get_around_owner/models/getaround_unavailabilities_created.rb +257 -0
  96. data/lib/get_around_owner/models/getaround_unavailabilities_created_all_of_data.rb +267 -0
  97. data/lib/get_around_owner/models/getaround_unavailabilities_deleted.rb +257 -0
  98. data/lib/get_around_owner/models/getaround_unavailabilities_deleted_all_of_data.rb +235 -0
  99. data/lib/get_around_owner/models/getaround_unavailability.rb +302 -0
  100. data/lib/get_around_owner/models/getaround_user.rb +420 -0
  101. data/lib/get_around_owner/models/getaround_users_updated.rb +257 -0
  102. data/lib/get_around_owner/models/getaround_users_updated_all_of_data.rb +215 -0
  103. data/lib/get_around_owner/models/getaround_webhook.rb +252 -0
  104. data/lib/get_around_owner/version.rb +15 -0
  105. data/lib/get_around_owner.rb +86 -0
  106. data/spec/api/cars_api_spec.rb +60 -0
  107. data/spec/api/checkins_api_spec.rb +62 -0
  108. data/spec/api/checkouts_api_spec.rb +62 -0
  109. data/spec/api/invoices_api_spec.rb +76 -0
  110. data/spec/api/messages_api_spec.rb +73 -0
  111. data/spec/api/payouts_api_spec.rb +62 -0
  112. data/spec/api/rentals_api_spec.rb +62 -0
  113. data/spec/api/unavailabilities_api_spec.rb +77 -0
  114. data/spec/api/users_api_spec.rb +47 -0
  115. data/spec/models/getaround_car_spec.rb +66 -0
  116. data/spec/models/getaround_cars_index_inner_spec.rb +36 -0
  117. data/spec/models/getaround_checkin_spec.rb +54 -0
  118. data/spec/models/getaround_checkins_index_inner_spec.rb +36 -0
  119. data/spec/models/getaround_checkout_spec.rb +60 -0
  120. data/spec/models/getaround_create_messages_request_spec.rb +36 -0
  121. data/spec/models/getaround_create_unavailabilities_request_spec.rb +52 -0
  122. data/spec/models/getaround_destroy_unavailability_request_spec.rb +42 -0
  123. data/spec/models/getaround_invoice_charges_inner_spec.rb +42 -0
  124. data/spec/models/getaround_invoice_spec.rb +92 -0
  125. data/spec/models/getaround_invoices_index_inner_spec.rb +36 -0
  126. data/spec/models/getaround_message_spec.rb +60 -0
  127. data/spec/models/getaround_messages_sent_all_of_data_spec.rb +42 -0
  128. data/spec/models/getaround_messages_sent_spec.rb +48 -0
  129. data/spec/models/getaround_payout_invoices_inner_spec.rb +36 -0
  130. data/spec/models/getaround_payout_spec.rb +70 -0
  131. data/spec/models/getaround_payouts_index_inner_spec.rb +36 -0
  132. data/spec/models/getaround_reason_spec.rb +30 -0
  133. data/spec/models/getaround_rental_invoices_index_inner_spec.rb +36 -0
  134. data/spec/models/getaround_rental_messages_index_inner_spec.rb +36 -0
  135. data/spec/models/getaround_rental_spec.rb +78 -0
  136. data/spec/models/getaround_rentals_booked_all_of_data_spec.rb +36 -0
  137. data/spec/models/getaround_rentals_booked_spec.rb +48 -0
  138. data/spec/models/getaround_rentals_canceled_spec.rb +48 -0
  139. data/spec/models/getaround_rentals_car_checked_in_spec.rb +48 -0
  140. data/spec/models/getaround_rentals_car_checked_out_spec.rb +48 -0
  141. data/spec/models/getaround_rentals_car_switched_spec.rb +48 -0
  142. data/spec/models/getaround_rentals_index_inner_spec.rb +36 -0
  143. data/spec/models/getaround_rentals_times_changed_spec.rb +48 -0
  144. data/spec/models/getaround_unavailabilities_created_all_of_data_spec.rb +54 -0
  145. data/spec/models/getaround_unavailabilities_created_spec.rb +48 -0
  146. data/spec/models/getaround_unavailabilities_deleted_all_of_data_spec.rb +48 -0
  147. data/spec/models/getaround_unavailabilities_deleted_spec.rb +48 -0
  148. data/spec/models/getaround_unavailability_spec.rb +58 -0
  149. data/spec/models/getaround_user_spec.rb +108 -0
  150. data/spec/models/getaround_users_updated_all_of_data_spec.rb +36 -0
  151. data/spec/models/getaround_users_updated_spec.rb +48 -0
  152. data/spec/models/getaround_webhook_spec.rb +48 -0
  153. data/spec/spec_helper.rb +111 -0
  154. metadata +283 -0
@@ -0,0 +1,60 @@
1
+ =begin
2
+ #Getaround Owner API
3
+
4
+ ## 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.
5
+
6
+ The version of the OpenAPI document: 1.0.0
7
+ Contact: owner-api@getaround.com
8
+ Generated by: https://openapi-generator.tech
9
+ Generator version: 7.6.0
10
+
11
+ =end
12
+
13
+ require 'spec_helper'
14
+ require 'json'
15
+
16
+ # Unit tests for GetAroundOwner::CarsApi
17
+ # Automatically generated by openapi-generator (https://openapi-generator.tech)
18
+ # Please update as you see appropriate
19
+ describe 'CarsApi' do
20
+ before do
21
+ # run before each test
22
+ @api_instance = GetAroundOwner::CarsApi.new
23
+ end
24
+
25
+ after do
26
+ # run after each test
27
+ end
28
+
29
+ describe 'test an instance of CarsApi' do
30
+ it 'should create an instance of CarsApi' do
31
+ expect(@api_instance).to be_instance_of(GetAroundOwner::CarsApi)
32
+ end
33
+ end
34
+
35
+ # unit tests for get_car_by_id
36
+ # Find a car by ID
37
+ # Find a car by ID
38
+ # @param id ID of car to return
39
+ # @param [Hash] opts the optional parameters
40
+ # @return [GetaroundCar]
41
+ describe 'get_car_by_id test' do
42
+ it 'should work' do
43
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
44
+ end
45
+ end
46
+
47
+ # unit tests for get_cars
48
+ # Find all cars
49
+ # Find all cars
50
+ # @param [Hash] opts the optional parameters
51
+ # @option opts [String] :page Page number
52
+ # @option opts [String] :per_page Page size
53
+ # @return [Array<GetaroundCarsIndexInner>]
54
+ describe 'get_cars test' do
55
+ it 'should work' do
56
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
57
+ end
58
+ end
59
+
60
+ end
@@ -0,0 +1,62 @@
1
+ =begin
2
+ #Getaround Owner API
3
+
4
+ ## 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.
5
+
6
+ The version of the OpenAPI document: 1.0.0
7
+ Contact: owner-api@getaround.com
8
+ Generated by: https://openapi-generator.tech
9
+ Generator version: 7.6.0
10
+
11
+ =end
12
+
13
+ require 'spec_helper'
14
+ require 'json'
15
+
16
+ # Unit tests for GetAroundOwner::CheckinsApi
17
+ # Automatically generated by openapi-generator (https://openapi-generator.tech)
18
+ # Please update as you see appropriate
19
+ describe 'CheckinsApi' do
20
+ before do
21
+ # run before each test
22
+ @api_instance = GetAroundOwner::CheckinsApi.new
23
+ end
24
+
25
+ after do
26
+ # run after each test
27
+ end
28
+
29
+ describe 'test an instance of CheckinsApi' do
30
+ it 'should create an instance of CheckinsApi' do
31
+ expect(@api_instance).to be_instance_of(GetAroundOwner::CheckinsApi)
32
+ end
33
+ end
34
+
35
+ # unit tests for get_checkin_by_rental_id
36
+ # Find a checkin by rental ID
37
+ # Find a checkin by rental ID
38
+ # @param rental_id ID of the rental related to the checkin to return
39
+ # @param [Hash] opts the optional parameters
40
+ # @return [GetaroundCheckin]
41
+ describe 'get_checkin_by_rental_id test' do
42
+ it 'should work' do
43
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
44
+ end
45
+ end
46
+
47
+ # unit tests for get_checkins
48
+ # List of checkins that occurred between two dates
49
+ # List of checkins that occurred between two dates
50
+ # @param start_date Start date and time in [ISO8601 format](https://www.iso.org/iso-8601-date-and-time-format.html)
51
+ # @param end_date End date and time in [ISO8601 format](https://www.iso.org/iso-8601-date-and-time-format.html)
52
+ # @param [Hash] opts the optional parameters
53
+ # @option opts [String] :page Page number
54
+ # @option opts [String] :per_page Page size
55
+ # @return [Array<GetaroundCheckinsIndexInner>]
56
+ describe 'get_checkins test' do
57
+ it 'should work' do
58
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
59
+ end
60
+ end
61
+
62
+ end
@@ -0,0 +1,62 @@
1
+ =begin
2
+ #Getaround Owner API
3
+
4
+ ## 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.
5
+
6
+ The version of the OpenAPI document: 1.0.0
7
+ Contact: owner-api@getaround.com
8
+ Generated by: https://openapi-generator.tech
9
+ Generator version: 7.6.0
10
+
11
+ =end
12
+
13
+ require 'spec_helper'
14
+ require 'json'
15
+
16
+ # Unit tests for GetAroundOwner::CheckoutsApi
17
+ # Automatically generated by openapi-generator (https://openapi-generator.tech)
18
+ # Please update as you see appropriate
19
+ describe 'CheckoutsApi' do
20
+ before do
21
+ # run before each test
22
+ @api_instance = GetAroundOwner::CheckoutsApi.new
23
+ end
24
+
25
+ after do
26
+ # run after each test
27
+ end
28
+
29
+ describe 'test an instance of CheckoutsApi' do
30
+ it 'should create an instance of CheckoutsApi' do
31
+ expect(@api_instance).to be_instance_of(GetAroundOwner::CheckoutsApi)
32
+ end
33
+ end
34
+
35
+ # unit tests for get_checkout_by_rental_id
36
+ # Find a checkout by rental ID
37
+ # Find a checkout by rental ID
38
+ # @param rental_id ID of the rental related to the checkout to return
39
+ # @param [Hash] opts the optional parameters
40
+ # @return [GetaroundCheckout]
41
+ describe 'get_checkout_by_rental_id test' do
42
+ it 'should work' do
43
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
44
+ end
45
+ end
46
+
47
+ # unit tests for get_checkouts
48
+ # List of checkouts that occurred between two dates
49
+ # List of checkouts that occurred between two dates
50
+ # @param start_date Start date and time in [ISO8601 format](https://www.iso.org/iso-8601-date-and-time-format.html)
51
+ # @param end_date End date and time in [ISO8601 format](https://www.iso.org/iso-8601-date-and-time-format.html)
52
+ # @param [Hash] opts the optional parameters
53
+ # @option opts [String] :page Page number
54
+ # @option opts [String] :per_page Page size
55
+ # @return [Array<GetaroundCheckinsIndexInner>]
56
+ describe 'get_checkouts test' do
57
+ it 'should work' do
58
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
59
+ end
60
+ end
61
+
62
+ end
@@ -0,0 +1,76 @@
1
+ =begin
2
+ #Getaround Owner API
3
+
4
+ ## 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.
5
+
6
+ The version of the OpenAPI document: 1.0.0
7
+ Contact: owner-api@getaround.com
8
+ Generated by: https://openapi-generator.tech
9
+ Generator version: 7.6.0
10
+
11
+ =end
12
+
13
+ require 'spec_helper'
14
+ require 'json'
15
+
16
+ # Unit tests for GetAroundOwner::InvoicesApi
17
+ # Automatically generated by openapi-generator (https://openapi-generator.tech)
18
+ # Please update as you see appropriate
19
+ describe 'InvoicesApi' do
20
+ before do
21
+ # run before each test
22
+ @api_instance = GetAroundOwner::InvoicesApi.new
23
+ end
24
+
25
+ after do
26
+ # run after each test
27
+ end
28
+
29
+ describe 'test an instance of InvoicesApi' do
30
+ it 'should create an instance of InvoicesApi' do
31
+ expect(@api_instance).to be_instance_of(GetAroundOwner::InvoicesApi)
32
+ end
33
+ end
34
+
35
+ # unit tests for get_invoice_by_id
36
+ # Find an invoice by ID
37
+ # Find an invoice by ID
38
+ # @param id ID of invoice to return
39
+ # @param [Hash] opts the optional parameters
40
+ # @return [GetaroundInvoice]
41
+ describe 'get_invoice_by_id test' do
42
+ it 'should work' do
43
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
44
+ end
45
+ end
46
+
47
+ # unit tests for get_invoices
48
+ # Find invoices emitted between dates
49
+ # Find invoices emitted between dates
50
+ # @param [Hash] opts the optional parameters
51
+ # @option opts [Time] :start_date Start date and time in [ISO8601 format](https://www.iso.org/iso-8601-date-and-time-format.html)
52
+ # @option opts [Time] :end_date End date and time in [ISO8601 format](https://www.iso.org/iso-8601-date-and-time-format.html)
53
+ # @option opts [String] :page Page number
54
+ # @option opts [String] :per_page Page size
55
+ # @return [Array<GetaroundInvoicesIndexInner>]
56
+ describe 'get_invoices test' do
57
+ it 'should work' do
58
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
59
+ end
60
+ end
61
+
62
+ # unit tests for get_invoices_for_rental
63
+ # Find invoices associated to a rental
64
+ # Find invoices associated to a rental
65
+ # @param rental_id ID of rental
66
+ # @param [Hash] opts the optional parameters
67
+ # @option opts [String] :page Page number
68
+ # @option opts [String] :per_page Page size
69
+ # @return [Array<GetaroundRentalInvoicesIndexInner>]
70
+ describe 'get_invoices_for_rental test' do
71
+ it 'should work' do
72
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
73
+ end
74
+ end
75
+
76
+ end
@@ -0,0 +1,73 @@
1
+ =begin
2
+ #Getaround Owner API
3
+
4
+ ## 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.
5
+
6
+ The version of the OpenAPI document: 1.0.0
7
+ Contact: owner-api@getaround.com
8
+ Generated by: https://openapi-generator.tech
9
+ Generator version: 7.6.0
10
+
11
+ =end
12
+
13
+ require 'spec_helper'
14
+ require 'json'
15
+
16
+ # Unit tests for GetAroundOwner::MessagesApi
17
+ # Automatically generated by openapi-generator (https://openapi-generator.tech)
18
+ # Please update as you see appropriate
19
+ describe 'MessagesApi' do
20
+ before do
21
+ # run before each test
22
+ @api_instance = GetAroundOwner::MessagesApi.new
23
+ end
24
+
25
+ after do
26
+ # run after each test
27
+ end
28
+
29
+ describe 'test an instance of MessagesApi' do
30
+ it 'should create an instance of MessagesApi' do
31
+ expect(@api_instance).to be_instance_of(GetAroundOwner::MessagesApi)
32
+ end
33
+ end
34
+
35
+ # unit tests for create_messages
36
+ # Create Message associated to a rental
37
+ # Create Message associated to a rental
38
+ # @param rental_id ID of rental
39
+ # @param [Hash] opts the optional parameters
40
+ # @option opts [GetaroundCreateMessagesRequest] :getaround_create_messages_request Message to create
41
+ # @return [GetaroundMessage]
42
+ describe 'create_messages test' do
43
+ it 'should work' do
44
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
45
+ end
46
+ end
47
+
48
+ # unit tests for get_message_by_id
49
+ # Find a message by ID associated to a rental
50
+ # Find a message by ID associated to a rental
51
+ # @param rental_id ID of rental
52
+ # @param id ID of message to return
53
+ # @param [Hash] opts the optional parameters
54
+ # @return [GetaroundMessage]
55
+ describe 'get_message_by_id test' do
56
+ it 'should work' do
57
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
58
+ end
59
+ end
60
+
61
+ # unit tests for get_messages_for_rental
62
+ # Find messages associated to a rental
63
+ # Find messages associated to a rental
64
+ # @param rental_id ID of rental
65
+ # @param [Hash] opts the optional parameters
66
+ # @return [Array<GetaroundRentalMessagesIndexInner>]
67
+ describe 'get_messages_for_rental test' do
68
+ it 'should work' do
69
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
70
+ end
71
+ end
72
+
73
+ end
@@ -0,0 +1,62 @@
1
+ =begin
2
+ #Getaround Owner API
3
+
4
+ ## 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.
5
+
6
+ The version of the OpenAPI document: 1.0.0
7
+ Contact: owner-api@getaround.com
8
+ Generated by: https://openapi-generator.tech
9
+ Generator version: 7.6.0
10
+
11
+ =end
12
+
13
+ require 'spec_helper'
14
+ require 'json'
15
+
16
+ # Unit tests for GetAroundOwner::PayoutsApi
17
+ # Automatically generated by openapi-generator (https://openapi-generator.tech)
18
+ # Please update as you see appropriate
19
+ describe 'PayoutsApi' do
20
+ before do
21
+ # run before each test
22
+ @api_instance = GetAroundOwner::PayoutsApi.new
23
+ end
24
+
25
+ after do
26
+ # run after each test
27
+ end
28
+
29
+ describe 'test an instance of PayoutsApi' do
30
+ it 'should create an instance of PayoutsApi' do
31
+ expect(@api_instance).to be_instance_of(GetAroundOwner::PayoutsApi)
32
+ end
33
+ end
34
+
35
+ # unit tests for get_payout_by_id
36
+ # Find a payout by ID
37
+ # Find a payout by ID
38
+ # @param id ID of payout to return
39
+ # @param [Hash] opts the optional parameters
40
+ # @return [GetaroundPayout]
41
+ describe 'get_payout_by_id test' do
42
+ it 'should work' do
43
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
44
+ end
45
+ end
46
+
47
+ # unit tests for get_payouts
48
+ # Find payouts paid between dates
49
+ # Find payouts paid between dates
50
+ # @param start_date Start date and time in [ISO8601 format](https://www.iso.org/iso-8601-date-and-time-format.html)
51
+ # @param end_date End date and time in [ISO8601 format](https://www.iso.org/iso-8601-date-and-time-format.html)
52
+ # @param [Hash] opts the optional parameters
53
+ # @option opts [String] :page Page number
54
+ # @option opts [String] :per_page Page size
55
+ # @return [Array<GetaroundPayoutsIndexInner>]
56
+ describe 'get_payouts test' do
57
+ it 'should work' do
58
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
59
+ end
60
+ end
61
+
62
+ end
@@ -0,0 +1,62 @@
1
+ =begin
2
+ #Getaround Owner API
3
+
4
+ ## 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.
5
+
6
+ The version of the OpenAPI document: 1.0.0
7
+ Contact: owner-api@getaround.com
8
+ Generated by: https://openapi-generator.tech
9
+ Generator version: 7.6.0
10
+
11
+ =end
12
+
13
+ require 'spec_helper'
14
+ require 'json'
15
+
16
+ # Unit tests for GetAroundOwner::RentalsApi
17
+ # Automatically generated by openapi-generator (https://openapi-generator.tech)
18
+ # Please update as you see appropriate
19
+ describe 'RentalsApi' do
20
+ before do
21
+ # run before each test
22
+ @api_instance = GetAroundOwner::RentalsApi.new
23
+ end
24
+
25
+ after do
26
+ # run after each test
27
+ end
28
+
29
+ describe 'test an instance of RentalsApi' do
30
+ it 'should create an instance of RentalsApi' do
31
+ expect(@api_instance).to be_instance_of(GetAroundOwner::RentalsApi)
32
+ end
33
+ end
34
+
35
+ # unit tests for get_rental_by_id
36
+ # Find a rental by ID
37
+ # Find a rental by ID
38
+ # @param id ID of rental to return
39
+ # @param [Hash] opts the optional parameters
40
+ # @return [GetaroundRental]
41
+ describe 'get_rental_by_id test' do
42
+ it 'should work' do
43
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
44
+ end
45
+ end
46
+
47
+ # unit tests for get_rentals
48
+ # Find rentals booked between dates
49
+ # Find rentals booked between dates
50
+ # @param start_date Start date and time in [ISO8601 format](https://www.iso.org/iso-8601-date-and-time-format.html)
51
+ # @param end_date End date and time in [ISO8601 format](https://www.iso.org/iso-8601-date-and-time-format.html)
52
+ # @param [Hash] opts the optional parameters
53
+ # @option opts [String] :page Page number
54
+ # @option opts [String] :per_page Page size
55
+ # @return [Array<GetaroundRentalsIndexInner>]
56
+ describe 'get_rentals test' do
57
+ it 'should work' do
58
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
59
+ end
60
+ end
61
+
62
+ end
@@ -0,0 +1,77 @@
1
+ =begin
2
+ #Getaround Owner API
3
+
4
+ ## 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.
5
+
6
+ The version of the OpenAPI document: 1.0.0
7
+ Contact: owner-api@getaround.com
8
+ Generated by: https://openapi-generator.tech
9
+ Generator version: 7.6.0
10
+
11
+ =end
12
+
13
+ require 'spec_helper'
14
+ require 'json'
15
+
16
+ # Unit tests for GetAroundOwner::UnavailabilitiesApi
17
+ # Automatically generated by openapi-generator (https://openapi-generator.tech)
18
+ # Please update as you see appropriate
19
+ describe 'UnavailabilitiesApi' do
20
+ before do
21
+ # run before each test
22
+ @api_instance = GetAroundOwner::UnavailabilitiesApi.new
23
+ end
24
+
25
+ after do
26
+ # run after each test
27
+ end
28
+
29
+ describe 'test an instance of UnavailabilitiesApi' do
30
+ it 'should create an instance of UnavailabilitiesApi' do
31
+ expect(@api_instance).to be_instance_of(GetAroundOwner::UnavailabilitiesApi)
32
+ end
33
+ end
34
+
35
+ # unit tests for create_unavailabilities
36
+ # Create Unavailability related to a car between dates
37
+ # Set a car as unavailable between 2 dates
38
+ # @param car_id ID of car
39
+ # @param [Hash] opts the optional parameters
40
+ # @option opts [GetaroundCreateUnavailabilitiesRequest] :getaround_create_unavailabilities_request Unavailability to create
41
+ # @return [nil]
42
+ describe 'create_unavailabilities test' do
43
+ it 'should work' do
44
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
45
+ end
46
+ end
47
+
48
+ # unit tests for destroy_unavailability
49
+ # Destroy Unavailability related to a car between dates
50
+ # Set a car as available between 2 dates
51
+ # @param car_id ID of car
52
+ # @param [Hash] opts the optional parameters
53
+ # @option opts [GetaroundDestroyUnavailabilityRequest] :getaround_destroy_unavailability_request Unavailability to destroy
54
+ # @return [nil]
55
+ describe 'destroy_unavailability test' do
56
+ it 'should work' do
57
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
58
+ end
59
+ end
60
+
61
+ # unit tests for get_unavailabilities_for_car
62
+ # Find Unavailabilities related to a car between dates
63
+ # Find between 2 dates when you’ve set a car as unavailable
64
+ # @param start_date Start date and time in [ISO8601 format](https://www.iso.org/iso-8601-date-and-time-format.html)
65
+ # @param end_date End date and time in [ISO8601 format](https://www.iso.org/iso-8601-date-and-time-format.html)
66
+ # @param car_id ID of the car
67
+ # @param [Hash] opts the optional parameters
68
+ # @option opts [String] :page Page number
69
+ # @option opts [String] :per_page Page size
70
+ # @return [Array<GetaroundUnavailability>]
71
+ describe 'get_unavailabilities_for_car test' do
72
+ it 'should work' do
73
+ # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
74
+ end
75
+ end
76
+
77
+ end