get_around_owner 1.0.1 → 1.0.4

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 (232) hide show
  1. checksums.yaml +4 -4
  2. data/Gemfile +9 -0
  3. data/Owner API v1.json +2938 -0
  4. data/README.md +359 -203
  5. data/Rakefile +8 -0
  6. data/docs/Car.md +12 -0
  7. data/docs/CarId.md +6 -0
  8. data/docs/CarIdUnavailabilitiesJsonBody.md +9 -0
  9. data/docs/CarsApi.md +109 -0
  10. data/docs/CarsIndex.md +6 -0
  11. data/docs/Checkin.md +10 -0
  12. data/docs/CheckinsApi.md +113 -0
  13. data/docs/CheckinsIndex.md +6 -0
  14. data/docs/Checkout.md +11 -0
  15. data/docs/CheckoutsApi.md +113 -0
  16. data/docs/CheckoutsIndex.md +6 -0
  17. data/docs/EndsAt.md +6 -0
  18. data/docs/GetaroundCar.md +28 -0
  19. data/docs/GetaroundCarsIndexInner.md +18 -0
  20. data/docs/GetaroundCheckin.md +24 -0
  21. data/docs/GetaroundCheckinsIndexInner.md +18 -0
  22. data/docs/GetaroundCheckout.md +26 -0
  23. data/docs/GetaroundCreateMessagesRequest.md +18 -0
  24. data/docs/GetaroundCreateUnavailabilitiesRequest.md +22 -0
  25. data/docs/GetaroundDestroyUnavailabilityRequest.md +20 -0
  26. data/docs/GetaroundInvoice.md +34 -0
  27. data/docs/GetaroundInvoiceChargesInner.md +20 -0
  28. data/docs/GetaroundInvoicesIndexInner.md +18 -0
  29. data/docs/GetaroundMessage.md +26 -0
  30. data/docs/GetaroundMessagesSent.md +22 -0
  31. data/docs/GetaroundMessagesSentAllOfData.md +20 -0
  32. data/docs/GetaroundPayout.md +28 -0
  33. data/docs/GetaroundPayoutInvoicesInner.md +18 -0
  34. data/docs/GetaroundPayoutsIndexInner.md +18 -0
  35. data/docs/GetaroundReason.md +15 -0
  36. data/docs/GetaroundRental.md +32 -0
  37. data/docs/GetaroundRentalInvoicesIndexInner.md +18 -0
  38. data/docs/GetaroundRentalMessagesIndexInner.md +18 -0
  39. data/docs/GetaroundRentalsBooked.md +22 -0
  40. data/docs/GetaroundRentalsBookedAllOfData.md +18 -0
  41. data/docs/GetaroundRentalsCanceled.md +22 -0
  42. data/docs/GetaroundRentalsCarCheckedIn.md +22 -0
  43. data/docs/GetaroundRentalsCarCheckedOut.md +22 -0
  44. data/docs/GetaroundRentalsCarSwitched.md +22 -0
  45. data/docs/GetaroundRentalsIndexInner.md +18 -0
  46. data/docs/GetaroundRentalsTimesChanged.md +22 -0
  47. data/docs/GetaroundUnavailabilitiesCreated.md +22 -0
  48. data/docs/GetaroundUnavailabilitiesCreatedAllOfData.md +24 -0
  49. data/docs/GetaroundUnavailabilitiesDeleted.md +22 -0
  50. data/docs/GetaroundUnavailabilitiesDeletedAllOfData.md +22 -0
  51. data/docs/GetaroundUnavailability.md +24 -0
  52. data/docs/GetaroundUser.md +42 -0
  53. data/docs/GetaroundUsersUpdated.md +22 -0
  54. data/docs/GetaroundUsersUpdatedAllOfData.md +18 -0
  55. data/docs/GetaroundWebhook.md +22 -0
  56. data/docs/Invoice.md +15 -0
  57. data/docs/InvoicesApi.md +168 -0
  58. data/docs/InvoicesIndex.md +6 -0
  59. data/docs/Message.md +11 -0
  60. data/docs/MessagesApi.md +161 -0
  61. data/docs/MessagesSent.md +6 -0
  62. data/docs/Payout.md +12 -0
  63. data/docs/PayoutsApi.md +113 -0
  64. data/docs/PayoutsIndex.md +6 -0
  65. data/docs/Rental.md +14 -0
  66. data/docs/RentalIdMessagesJsonBody.md +7 -0
  67. data/docs/RentalInvoicesIndex.md +6 -0
  68. data/docs/RentalMessagesIndex.md +6 -0
  69. data/docs/RentalsApi.md +113 -0
  70. data/docs/RentalsBooked.md +6 -0
  71. data/docs/RentalsCanceled.md +6 -0
  72. data/docs/RentalsCarCheckedIn.md +6 -0
  73. data/docs/RentalsCarCheckedOut.md +6 -0
  74. data/docs/RentalsCarSwitched.md +6 -0
  75. data/docs/RentalsIndex.md +6 -0
  76. data/docs/RentalsTimesChanged.md +6 -0
  77. data/docs/StartsAt.md +6 -0
  78. data/docs/UnavailabilitiesApi.md +166 -0
  79. data/docs/UnavailabilitiesCreated.md +6 -0
  80. data/docs/UnavailabilitiesDeleted.md +6 -0
  81. data/docs/UnavailabilitiesIndex.md +6 -0
  82. data/docs/Unavailability.md +10 -0
  83. data/docs/User.md +19 -0
  84. data/docs/UsersApi.md +56 -0
  85. data/docs/UsersUpdated.md +6 -0
  86. data/docs/Webhook.md +9 -0
  87. data/get_around_owner-1.0.0.gem +0 -0
  88. data/get_around_owner-1.0.1.gem +0 -0
  89. data/get_around_owner-1.0.3.gem +0 -0
  90. data/get_around_owner.gemspec +39 -0
  91. data/getaround-api.gemspec +38 -0
  92. data/git_push.sh +55 -0
  93. data/lib/get_around_owner/api/cars_api.rb +25 -41
  94. data/lib/get_around_owner/api/checkins_api.rb +99 -35
  95. data/lib/get_around_owner/api/checkouts_api.rb +99 -35
  96. data/lib/get_around_owner/api/invoices_api.rb +43 -66
  97. data/lib/get_around_owner/api/messages_api.rb +149 -33
  98. data/lib/get_around_owner/api/payouts_api.rb +29 -45
  99. data/lib/get_around_owner/api/rentals_api.rb +67 -183
  100. data/lib/get_around_owner/api/unavailabilities_api.rb +124 -58
  101. data/lib/get_around_owner/api/users_api.rb +30 -36
  102. data/lib/get_around_owner/api_client.rb +71 -77
  103. data/lib/get_around_owner/api_error.rb +5 -6
  104. data/lib/get_around_owner/configuration.rb +13 -106
  105. data/lib/get_around_owner/models/{getaround_car.rb → car.rb} +36 -56
  106. data/lib/get_around_owner/models/{getaround_users_updated_all_of_data.rb → car_id.rb} +33 -50
  107. data/lib/get_around_owner/models/{getaround_destroy_unavailability_request.rb → car_id_unavailabilities_json_body.rb} +45 -47
  108. data/lib/get_around_owner/models/{getaround_rentals_booked_all_of_data.rb → cars_index.rb} +33 -50
  109. data/lib/get_around_owner/models/{getaround_checkin.rb → checkin.rb} +34 -65
  110. data/lib/get_around_owner/models/{getaround_payouts_index_inner.rb → checkins_index.rb} +32 -58
  111. data/lib/get_around_owner/models/{getaround_checkout.rb → checkout.rb} +35 -70
  112. data/lib/get_around_owner/models/checkouts_index.rb +197 -0
  113. data/lib/get_around_owner/models/ends_at.rb +198 -0
  114. data/lib/get_around_owner/models/{getaround_invoice.rb → invoice.rb} +45 -113
  115. data/lib/get_around_owner/models/invoices_index.rb +198 -0
  116. data/lib/get_around_owner/models/{getaround_message.rb → message.rb} +35 -53
  117. data/lib/get_around_owner/models/messages_sent.rb +197 -0
  118. data/lib/get_around_owner/models/{getaround_payout.rb → payout.rb} +37 -101
  119. data/lib/get_around_owner/models/payouts_index.rb +198 -0
  120. data/lib/get_around_owner/models/{getaround_rental.rb → rental.rb} +38 -100
  121. data/lib/get_around_owner/models/{getaround_create_messages_request.rb → rental_id_messages_json_body.rb} +31 -41
  122. data/lib/get_around_owner/models/rental_invoices_index.rb +198 -0
  123. data/lib/get_around_owner/models/rental_messages_index.rb +198 -0
  124. data/lib/get_around_owner/models/rentals_booked.rb +197 -0
  125. data/lib/get_around_owner/models/rentals_canceled.rb +197 -0
  126. data/lib/get_around_owner/models/rentals_car_checked_in.rb +197 -0
  127. data/lib/get_around_owner/models/rentals_car_checked_out.rb +197 -0
  128. data/lib/get_around_owner/models/rentals_car_switched.rb +197 -0
  129. data/lib/get_around_owner/models/rentals_index.rb +198 -0
  130. data/lib/get_around_owner/models/rentals_times_changed.rb +197 -0
  131. data/lib/get_around_owner/models/starts_at.rb +198 -0
  132. data/lib/get_around_owner/models/{getaround_cars_index_inner.rb → unavailabilities_created.rb} +32 -58
  133. data/lib/get_around_owner/models/unavailabilities_deleted.rb +197 -0
  134. data/lib/get_around_owner/models/unavailabilities_index.rb +198 -0
  135. data/lib/get_around_owner/models/{getaround_unavailabilities_created_all_of_data.rb → unavailability.rb} +51 -65
  136. data/lib/get_around_owner/models/{getaround_user.rb → user.rb} +43 -75
  137. data/lib/get_around_owner/models/users_updated.rb +197 -0
  138. data/lib/get_around_owner/models/{getaround_webhook.rb → webhook.rb} +38 -47
  139. data/lib/get_around_owner/version.rb +5 -6
  140. data/lib/get_around_owner.rb +38 -43
  141. data/openapi.yml +2298 -0
  142. data/spec/api/cars_api_spec.rb +13 -14
  143. data/spec/api/checkins_api_spec.rb +13 -14
  144. data/spec/api/checkouts_api_spec.rb +13 -14
  145. data/spec/api/invoices_api_spec.rb +19 -20
  146. data/spec/api/messages_api_spec.rb +14 -15
  147. data/spec/api/payouts_api_spec.rb +13 -14
  148. data/spec/api/rentals_api_spec.rb +13 -14
  149. data/spec/api/unavailabilities_api_spec.rb +14 -16
  150. data/spec/api/users_api_spec.rb +9 -10
  151. data/spec/api_client_spec.rb +225 -0
  152. data/spec/base_object_spec.rb +109 -0
  153. data/spec/{models/getaround_checkins_index_inner_spec.rb → configuration_spec.rb} +26 -21
  154. data/spec/models/{getaround_reason_spec.rb → car_id_spec.rb} +18 -14
  155. data/spec/models/{getaround_unavailabilities_deleted_all_of_data_spec.rb → car_id_unavailabilities_json_body_spec.rb} +24 -20
  156. data/spec/models/{getaround_car_spec.rb → car_spec.rb} +24 -20
  157. data/spec/models/{getaround_rentals_index_inner_spec.rb → cars_index_spec.rb} +16 -18
  158. data/spec/models/{getaround_checkin_spec.rb → checkin_spec.rb} +22 -18
  159. data/spec/models/checkins_index_spec.rb +34 -0
  160. data/spec/models/{getaround_checkout_spec.rb → checkout_spec.rb} +23 -19
  161. data/spec/models/checkouts_index_spec.rb +34 -0
  162. data/spec/models/ends_at_spec.rb +34 -0
  163. data/spec/models/{getaround_invoice_spec.rb → invoice_spec.rb} +27 -31
  164. data/spec/models/invoices_index_spec.rb +34 -0
  165. data/spec/models/{getaround_message_spec.rb → message_spec.rb} +23 -19
  166. data/spec/models/messages_sent_spec.rb +34 -0
  167. data/spec/models/{getaround_payout_spec.rb → payout_spec.rb} +24 -24
  168. data/spec/models/payouts_index_spec.rb +34 -0
  169. data/spec/models/{getaround_create_messages_request_spec.rb → rental_id_messages_json_body_spec.rb} +19 -15
  170. data/spec/models/rental_invoices_index_spec.rb +34 -0
  171. data/spec/models/rental_messages_index_spec.rb +34 -0
  172. data/spec/models/{getaround_rental_spec.rb → rental_spec.rb} +26 -22
  173. data/spec/models/rentals_booked_spec.rb +34 -0
  174. data/spec/models/rentals_canceled_spec.rb +34 -0
  175. data/spec/models/rentals_car_checked_in_spec.rb +34 -0
  176. data/spec/models/rentals_car_checked_out_spec.rb +34 -0
  177. data/spec/models/rentals_car_switched_spec.rb +34 -0
  178. data/spec/models/rentals_index_spec.rb +34 -0
  179. data/spec/models/rentals_times_changed_spec.rb +34 -0
  180. data/spec/models/starts_at_spec.rb +34 -0
  181. data/spec/models/{getaround_cars_index_inner_spec.rb → unavailabilities_created_spec.rb} +16 -18
  182. data/spec/models/{getaround_payouts_index_inner_spec.rb → unavailabilities_deleted_spec.rb} +16 -18
  183. data/spec/models/unavailabilities_index_spec.rb +34 -0
  184. data/spec/models/{getaround_unavailabilities_created_all_of_data_spec.rb → unavailability_spec.rb} +22 -18
  185. data/spec/models/{getaround_user_spec.rb → user_spec.rb} +31 -27
  186. data/spec/models/users_updated_spec.rb +34 -0
  187. data/spec/models/{getaround_webhook_spec.rb → webhook_spec.rb} +21 -17
  188. data/spec/spec_helper.rb +4 -5
  189. metadata +276 -119
  190. data/lib/get_around_owner/models/getaround_checkins_index_inner.rb +0 -222
  191. data/lib/get_around_owner/models/getaround_create_unavailabilities_request.rb +0 -283
  192. data/lib/get_around_owner/models/getaround_invoice_charges_inner.rb +0 -225
  193. data/lib/get_around_owner/models/getaround_invoices_index_inner.rb +0 -223
  194. data/lib/get_around_owner/models/getaround_messages_sent.rb +0 -257
  195. data/lib/get_around_owner/models/getaround_messages_sent_all_of_data.rb +0 -225
  196. data/lib/get_around_owner/models/getaround_payout_invoices_inner.rb +0 -223
  197. data/lib/get_around_owner/models/getaround_reason.rb +0 -45
  198. data/lib/get_around_owner/models/getaround_rental_invoices_index_inner.rb +0 -223
  199. data/lib/get_around_owner/models/getaround_rental_messages_index_inner.rb +0 -223
  200. data/lib/get_around_owner/models/getaround_rentals_booked.rb +0 -257
  201. data/lib/get_around_owner/models/getaround_rentals_canceled.rb +0 -257
  202. data/lib/get_around_owner/models/getaround_rentals_car_checked_in.rb +0 -257
  203. data/lib/get_around_owner/models/getaround_rentals_car_checked_out.rb +0 -257
  204. data/lib/get_around_owner/models/getaround_rentals_car_switched.rb +0 -257
  205. data/lib/get_around_owner/models/getaround_rentals_index_inner.rb +0 -223
  206. data/lib/get_around_owner/models/getaround_rentals_times_changed.rb +0 -257
  207. data/lib/get_around_owner/models/getaround_unavailabilities_created.rb +0 -257
  208. data/lib/get_around_owner/models/getaround_unavailabilities_deleted.rb +0 -257
  209. data/lib/get_around_owner/models/getaround_unavailabilities_deleted_all_of_data.rb +0 -235
  210. data/lib/get_around_owner/models/getaround_unavailability.rb +0 -302
  211. data/lib/get_around_owner/models/getaround_users_updated.rb +0 -257
  212. data/spec/models/getaround_create_unavailabilities_request_spec.rb +0 -52
  213. data/spec/models/getaround_destroy_unavailability_request_spec.rb +0 -42
  214. data/spec/models/getaround_invoice_charges_inner_spec.rb +0 -42
  215. data/spec/models/getaround_invoices_index_inner_spec.rb +0 -36
  216. data/spec/models/getaround_messages_sent_all_of_data_spec.rb +0 -42
  217. data/spec/models/getaround_messages_sent_spec.rb +0 -48
  218. data/spec/models/getaround_payout_invoices_inner_spec.rb +0 -36
  219. data/spec/models/getaround_rental_invoices_index_inner_spec.rb +0 -36
  220. data/spec/models/getaround_rental_messages_index_inner_spec.rb +0 -36
  221. data/spec/models/getaround_rentals_booked_all_of_data_spec.rb +0 -36
  222. data/spec/models/getaround_rentals_booked_spec.rb +0 -48
  223. data/spec/models/getaround_rentals_canceled_spec.rb +0 -48
  224. data/spec/models/getaround_rentals_car_checked_in_spec.rb +0 -48
  225. data/spec/models/getaround_rentals_car_checked_out_spec.rb +0 -48
  226. data/spec/models/getaround_rentals_car_switched_spec.rb +0 -48
  227. data/spec/models/getaround_rentals_times_changed_spec.rb +0 -48
  228. data/spec/models/getaround_unavailabilities_created_spec.rb +0 -48
  229. data/spec/models/getaround_unavailabilities_deleted_spec.rb +0 -48
  230. data/spec/models/getaround_unavailability_spec.rb +0 -58
  231. data/spec/models/getaround_users_updated_all_of_data_spec.rb +0 -36
  232. data/spec/models/getaround_users_updated_spec.rb +0 -48
@@ -1,25 +1,24 @@
1
1
  =begin
2
2
  #Getaround Owner API
3
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.
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
5
 
6
- The version of the OpenAPI document: 1.0.0
6
+ OpenAPI spec version: 1.0.0
7
7
  Contact: owner-api@getaround.com
8
- Generated by: https://openapi-generator.tech
9
- Generator version: 7.6.0
10
-
8
+ Generated by: https://github.com/swagger-api/swagger-codegen.git
9
+ Swagger Codegen version: 3.0.66
11
10
  =end
12
11
 
13
12
  require 'spec_helper'
14
13
  require 'json'
15
14
 
16
15
  # Unit tests for GetAroundOwner::PayoutsApi
17
- # Automatically generated by openapi-generator (https://openapi-generator.tech)
16
+ # Automatically generated by swagger-codegen (github.com/swagger-api/swagger-codegen)
18
17
  # Please update as you see appropriate
19
18
  describe 'PayoutsApi' do
20
19
  before do
21
20
  # run before each test
22
- @api_instance = GetAroundOwner::PayoutsApi.new
21
+ @instance = GetAroundOwner::PayoutsApi.new
23
22
  end
24
23
 
25
24
  after do
@@ -28,7 +27,7 @@ describe 'PayoutsApi' do
28
27
 
29
28
  describe 'test an instance of PayoutsApi' do
30
29
  it 'should create an instance of PayoutsApi' do
31
- expect(@api_instance).to be_instance_of(GetAroundOwner::PayoutsApi)
30
+ expect(@instance).to be_instance_of(GetAroundOwner::PayoutsApi)
32
31
  end
33
32
  end
34
33
 
@@ -37,10 +36,10 @@ describe 'PayoutsApi' do
37
36
  # Find a payout by ID
38
37
  # @param id ID of payout to return
39
38
  # @param [Hash] opts the optional parameters
40
- # @return [GetaroundPayout]
39
+ # @return [Payout]
41
40
  describe 'get_payout_by_id test' do
42
41
  it 'should work' do
43
- # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
42
+ # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
44
43
  end
45
44
  end
46
45
 
@@ -50,12 +49,12 @@ describe 'PayoutsApi' do
50
49
  # @param start_date Start date and time in [ISO8601 format](https://www.iso.org/iso-8601-date-and-time-format.html)
51
50
  # @param end_date End date and time in [ISO8601 format](https://www.iso.org/iso-8601-date-and-time-format.html)
52
51
  # @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>]
52
+ # @option opts [] :page Page number
53
+ # @option opts [] :per_page Page size
54
+ # @return [PayoutsIndex]
56
55
  describe 'get_payouts test' do
57
56
  it 'should work' do
58
- # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
57
+ # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
59
58
  end
60
59
  end
61
60
 
@@ -1,25 +1,24 @@
1
1
  =begin
2
2
  #Getaround Owner API
3
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.
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
5
 
6
- The version of the OpenAPI document: 1.0.0
6
+ OpenAPI spec version: 1.0.0
7
7
  Contact: owner-api@getaround.com
8
- Generated by: https://openapi-generator.tech
9
- Generator version: 7.6.0
10
-
8
+ Generated by: https://github.com/swagger-api/swagger-codegen.git
9
+ Swagger Codegen version: 3.0.66
11
10
  =end
12
11
 
13
12
  require 'spec_helper'
14
13
  require 'json'
15
14
 
16
15
  # Unit tests for GetAroundOwner::RentalsApi
17
- # Automatically generated by openapi-generator (https://openapi-generator.tech)
16
+ # Automatically generated by swagger-codegen (github.com/swagger-api/swagger-codegen)
18
17
  # Please update as you see appropriate
19
18
  describe 'RentalsApi' do
20
19
  before do
21
20
  # run before each test
22
- @api_instance = GetAroundOwner::RentalsApi.new
21
+ @instance = GetAroundOwner::RentalsApi.new
23
22
  end
24
23
 
25
24
  after do
@@ -28,7 +27,7 @@ describe 'RentalsApi' do
28
27
 
29
28
  describe 'test an instance of RentalsApi' do
30
29
  it 'should create an instance of RentalsApi' do
31
- expect(@api_instance).to be_instance_of(GetAroundOwner::RentalsApi)
30
+ expect(@instance).to be_instance_of(GetAroundOwner::RentalsApi)
32
31
  end
33
32
  end
34
33
 
@@ -37,10 +36,10 @@ describe 'RentalsApi' do
37
36
  # Find a rental by ID
38
37
  # @param id ID of rental to return
39
38
  # @param [Hash] opts the optional parameters
40
- # @return [GetaroundRental]
39
+ # @return [Rental]
41
40
  describe 'get_rental_by_id test' do
42
41
  it 'should work' do
43
- # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
42
+ # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
44
43
  end
45
44
  end
46
45
 
@@ -50,12 +49,12 @@ describe 'RentalsApi' do
50
49
  # @param start_date Start date and time in [ISO8601 format](https://www.iso.org/iso-8601-date-and-time-format.html)
51
50
  # @param end_date End date and time in [ISO8601 format](https://www.iso.org/iso-8601-date-and-time-format.html)
52
51
  # @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>]
52
+ # @option opts [] :page Page number
53
+ # @option opts [] :per_page Page size
54
+ # @return [RentalsIndex]
56
55
  describe 'get_rentals test' do
57
56
  it 'should work' do
58
- # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
57
+ # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
59
58
  end
60
59
  end
61
60
 
@@ -1,25 +1,24 @@
1
1
  =begin
2
2
  #Getaround Owner API
3
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.
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
5
 
6
- The version of the OpenAPI document: 1.0.0
6
+ OpenAPI spec version: 1.0.0
7
7
  Contact: owner-api@getaround.com
8
- Generated by: https://openapi-generator.tech
9
- Generator version: 7.6.0
10
-
8
+ Generated by: https://github.com/swagger-api/swagger-codegen.git
9
+ Swagger Codegen version: 3.0.66
11
10
  =end
12
11
 
13
12
  require 'spec_helper'
14
13
  require 'json'
15
14
 
16
15
  # Unit tests for GetAroundOwner::UnavailabilitiesApi
17
- # Automatically generated by openapi-generator (https://openapi-generator.tech)
16
+ # Automatically generated by swagger-codegen (github.com/swagger-api/swagger-codegen)
18
17
  # Please update as you see appropriate
19
18
  describe 'UnavailabilitiesApi' do
20
19
  before do
21
20
  # run before each test
22
- @api_instance = GetAroundOwner::UnavailabilitiesApi.new
21
+ @instance = GetAroundOwner::UnavailabilitiesApi.new
23
22
  end
24
23
 
25
24
  after do
@@ -28,7 +27,7 @@ describe 'UnavailabilitiesApi' do
28
27
 
29
28
  describe 'test an instance of UnavailabilitiesApi' do
30
29
  it 'should create an instance of UnavailabilitiesApi' do
31
- expect(@api_instance).to be_instance_of(GetAroundOwner::UnavailabilitiesApi)
30
+ expect(@instance).to be_instance_of(GetAroundOwner::UnavailabilitiesApi)
32
31
  end
33
32
  end
34
33
 
@@ -37,11 +36,11 @@ describe 'UnavailabilitiesApi' do
37
36
  # Set a car as unavailable between 2 dates
38
37
  # @param car_id ID of car
39
38
  # @param [Hash] opts the optional parameters
40
- # @option opts [GetaroundCreateUnavailabilitiesRequest] :getaround_create_unavailabilities_request Unavailability to create
39
+ # @option opts [CarIdUnavailabilitiesJsonBody] :body Unavailability to create
41
40
  # @return [nil]
42
41
  describe 'create_unavailabilities test' do
43
42
  it 'should work' do
44
- # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
43
+ # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
45
44
  end
46
45
  end
47
46
 
@@ -50,11 +49,10 @@ describe 'UnavailabilitiesApi' do
50
49
  # Set a car as available between 2 dates
51
50
  # @param car_id ID of car
52
51
  # @param [Hash] opts the optional parameters
53
- # @option opts [GetaroundDestroyUnavailabilityRequest] :getaround_destroy_unavailability_request Unavailability to destroy
54
52
  # @return [nil]
55
53
  describe 'destroy_unavailability test' do
56
54
  it 'should work' do
57
- # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
55
+ # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
58
56
  end
59
57
  end
60
58
 
@@ -65,12 +63,12 @@ describe 'UnavailabilitiesApi' do
65
63
  # @param end_date End date and time in [ISO8601 format](https://www.iso.org/iso-8601-date-and-time-format.html)
66
64
  # @param car_id ID of the car
67
65
  # @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>]
66
+ # @option opts [] :page Page number
67
+ # @option opts [] :per_page Page size
68
+ # @return [UnavailabilitiesIndex]
71
69
  describe 'get_unavailabilities_for_car test' do
72
70
  it 'should work' do
73
- # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
71
+ # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
74
72
  end
75
73
  end
76
74
 
@@ -1,25 +1,24 @@
1
1
  =begin
2
2
  #Getaround Owner API
3
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.
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
5
 
6
- The version of the OpenAPI document: 1.0.0
6
+ OpenAPI spec version: 1.0.0
7
7
  Contact: owner-api@getaround.com
8
- Generated by: https://openapi-generator.tech
9
- Generator version: 7.6.0
10
-
8
+ Generated by: https://github.com/swagger-api/swagger-codegen.git
9
+ Swagger Codegen version: 3.0.66
11
10
  =end
12
11
 
13
12
  require 'spec_helper'
14
13
  require 'json'
15
14
 
16
15
  # Unit tests for GetAroundOwner::UsersApi
17
- # Automatically generated by openapi-generator (https://openapi-generator.tech)
16
+ # Automatically generated by swagger-codegen (github.com/swagger-api/swagger-codegen)
18
17
  # Please update as you see appropriate
19
18
  describe 'UsersApi' do
20
19
  before do
21
20
  # run before each test
22
- @api_instance = GetAroundOwner::UsersApi.new
21
+ @instance = GetAroundOwner::UsersApi.new
23
22
  end
24
23
 
25
24
  after do
@@ -28,7 +27,7 @@ describe 'UsersApi' do
28
27
 
29
28
  describe 'test an instance of UsersApi' do
30
29
  it 'should create an instance of UsersApi' do
31
- expect(@api_instance).to be_instance_of(GetAroundOwner::UsersApi)
30
+ expect(@instance).to be_instance_of(GetAroundOwner::UsersApi)
32
31
  end
33
32
  end
34
33
 
@@ -37,10 +36,10 @@ describe 'UsersApi' do
37
36
  # Find a user by ID (Users are customers who rent one of your cars)
38
37
  # @param id ID of user to return
39
38
  # @param [Hash] opts the optional parameters
40
- # @return [GetaroundUser]
39
+ # @return [User]
41
40
  describe 'get_user_by_id test' do
42
41
  it 'should work' do
43
- # assertion here. ref: https://rspec.info/features/3-12/rspec-expectations/built-in-matchers/
42
+ # assertion here. ref: https://www.relishapp.com/rspec/rspec-expectations/docs/built-in-matchers
44
43
  end
45
44
  end
46
45
 
@@ -0,0 +1,225 @@
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
+ OpenAPI spec version: 1.0.0
7
+ Contact: owner-api@getaround.com
8
+ Generated by: https://github.com/swagger-api/swagger-codegen.git
9
+ Swagger Codegen version: 3.0.66
10
+ =end
11
+
12
+ require 'spec_helper'
13
+
14
+ describe GetAroundOwner::ApiClient do
15
+ context 'initialization' do
16
+ context 'URL stuff' do
17
+ context 'host' do
18
+ it 'removes http from host' do
19
+ GetAroundOwner.configure { |c| c.host = 'http://example.com' }
20
+ expect(GetAroundOwner::Configuration.default.host).to eq('example.com')
21
+ end
22
+
23
+ it 'removes https from host' do
24
+ GetAroundOwner.configure { |c| c.host = 'https://wookiee.com' }
25
+ expect(GetAroundOwner::ApiClient.default.config.host).to eq('wookiee.com')
26
+ end
27
+
28
+ it 'removes trailing path from host' do
29
+ GetAroundOwner.configure { |c| c.host = 'hobo.com/v4' }
30
+ expect(GetAroundOwner::Configuration.default.host).to eq('hobo.com')
31
+ end
32
+ end
33
+
34
+ context 'base_path' do
35
+ it "prepends a slash to base_path" do
36
+ GetAroundOwner.configure { |c| c.base_path = 'v4/dog' }
37
+ expect(GetAroundOwner::Configuration.default.base_path).to eq('/v4/dog')
38
+ end
39
+
40
+ it "doesn't prepend a slash if one is already there" do
41
+ GetAroundOwner.configure { |c| c.base_path = '/v4/dog' }
42
+ expect(GetAroundOwner::Configuration.default.base_path).to eq('/v4/dog')
43
+ end
44
+
45
+ it "ends up as a blank string if nil" do
46
+ GetAroundOwner.configure { |c| c.base_path = nil }
47
+ expect(GetAroundOwner::Configuration.default.base_path).to eq('')
48
+ end
49
+ end
50
+ end
51
+ end
52
+
53
+ describe 'params_encoding in #build_request' do
54
+ let(:config) { GetAroundOwner::Configuration.new }
55
+ let(:api_client) { GetAroundOwner::ApiClient.new(config) }
56
+
57
+ it 'defaults to nil' do
58
+ expect(GetAroundOwner::Configuration.default.params_encoding).to eq(nil)
59
+ expect(config.params_encoding).to eq(nil)
60
+
61
+ request = api_client.build_request(:get, '/test')
62
+ expect(request.options[:params_encoding]).to eq(nil)
63
+ end
64
+
65
+ it 'can be customized' do
66
+ config.params_encoding = :multi
67
+ request = api_client.build_request(:get, '/test')
68
+ expect(request.options[:params_encoding]).to eq(:multi)
69
+ end
70
+ end
71
+
72
+ describe 'timeout in #build_request' do
73
+ let(:config) { GetAroundOwner::Configuration.new }
74
+ let(:api_client) { GetAroundOwner::ApiClient.new(config) }
75
+
76
+ it 'defaults to 0' do
77
+ expect(GetAroundOwner::Configuration.default.timeout).to eq(0)
78
+ expect(config.timeout).to eq(0)
79
+
80
+ request = api_client.build_request(:get, '/test')
81
+ expect(request.options[:timeout]).to eq(0)
82
+ end
83
+
84
+ it 'can be customized' do
85
+ config.timeout = 100
86
+ request = api_client.build_request(:get, '/test')
87
+ expect(request.options[:timeout]).to eq(100)
88
+ end
89
+ end
90
+
91
+ describe '#deserialize' do
92
+ it "handles Array<Integer>" do
93
+ api_client = GetAroundOwner::ApiClient.new
94
+ headers = { 'Content-Type' => 'application/json' }
95
+ response = double('response', headers: headers, body: '[12, 34]')
96
+ data = api_client.deserialize(response, 'Array<Integer>')
97
+ expect(data).to be_instance_of(Array)
98
+ expect(data).to eq([12, 34])
99
+ end
100
+
101
+ it 'handles Array<Array<Integer>>' do
102
+ api_client = GetAroundOwner::ApiClient.new
103
+ headers = { 'Content-Type' => 'application/json' }
104
+ response = double('response', headers: headers, body: '[[12, 34], [56]]')
105
+ data = api_client.deserialize(response, 'Array<Array<Integer>>')
106
+ expect(data).to be_instance_of(Array)
107
+ expect(data).to eq([[12, 34], [56]])
108
+ end
109
+
110
+ it 'handles Hash<String, String>' do
111
+ api_client = GetAroundOwner::ApiClient.new
112
+ headers = { 'Content-Type' => 'application/json' }
113
+ response = double('response', headers: headers, body: '{"message": "Hello"}')
114
+ data = api_client.deserialize(response, 'Hash<String, String>')
115
+ expect(data).to be_instance_of(Hash)
116
+ expect(data).to eq(:message => 'Hello')
117
+ end
118
+ end
119
+
120
+ describe "#object_to_hash" do
121
+ it 'ignores nils and includes empty arrays' do
122
+ # uncomment below to test object_to_hash for model
123
+ # api_client = GetAroundOwner::ApiClient.new
124
+ # _model = GetAroundOwner::ModelName.new
125
+ # update the model attribute below
126
+ # _model.id = 1
127
+ # update the expected value (hash) below
128
+ # expected = {id: 1, name: '', tags: []}
129
+ # expect(api_client.object_to_hash(_model)).to eq(expected)
130
+ end
131
+ end
132
+
133
+ describe '#build_collection_param' do
134
+ let(:param) { ['aa', 'bb', 'cc'] }
135
+ let(:api_client) { GetAroundOwner::ApiClient.new }
136
+
137
+ it 'works for csv' do
138
+ expect(api_client.build_collection_param(param, :csv)).to eq('aa,bb,cc')
139
+ end
140
+
141
+ it 'works for ssv' do
142
+ expect(api_client.build_collection_param(param, :ssv)).to eq('aa bb cc')
143
+ end
144
+
145
+ it 'works for tsv' do
146
+ expect(api_client.build_collection_param(param, :tsv)).to eq("aa\tbb\tcc")
147
+ end
148
+
149
+ it 'works for pipes' do
150
+ expect(api_client.build_collection_param(param, :pipes)).to eq('aa|bb|cc')
151
+ end
152
+
153
+ it 'works for multi' do
154
+ expect(api_client.build_collection_param(param, :multi)).to eq(['aa', 'bb', 'cc'])
155
+ end
156
+
157
+ it 'fails for invalid collection format' do
158
+ expect(proc { api_client.build_collection_param(param, :INVALID) }).to raise_error(RuntimeError, 'unknown collection format: :INVALID')
159
+ end
160
+ end
161
+
162
+ describe '#json_mime?' do
163
+ let(:api_client) { GetAroundOwner::ApiClient.new }
164
+
165
+ it 'works' do
166
+ expect(api_client.json_mime?(nil)).to eq false
167
+ expect(api_client.json_mime?('')).to eq false
168
+
169
+ expect(api_client.json_mime?('application/json')).to eq true
170
+ expect(api_client.json_mime?('application/json; charset=UTF8')).to eq true
171
+ expect(api_client.json_mime?('APPLICATION/JSON')).to eq true
172
+
173
+ expect(api_client.json_mime?('application/xml')).to eq false
174
+ expect(api_client.json_mime?('text/plain')).to eq false
175
+ expect(api_client.json_mime?('application/jsonp')).to eq false
176
+ end
177
+ end
178
+
179
+ describe '#select_header_accept' do
180
+ let(:api_client) { GetAroundOwner::ApiClient.new }
181
+
182
+ it 'works' do
183
+ expect(api_client.select_header_accept(nil)).to be_nil
184
+ expect(api_client.select_header_accept([])).to be_nil
185
+
186
+ expect(api_client.select_header_accept(['application/json'])).to eq('application/json')
187
+ expect(api_client.select_header_accept(['application/xml', 'application/json; charset=UTF8'])).to eq('application/json; charset=UTF8')
188
+ expect(api_client.select_header_accept(['APPLICATION/JSON', 'text/html'])).to eq('APPLICATION/JSON')
189
+
190
+ expect(api_client.select_header_accept(['application/xml'])).to eq('application/xml')
191
+ expect(api_client.select_header_accept(['text/html', 'application/xml'])).to eq('text/html,application/xml')
192
+ end
193
+ end
194
+
195
+ describe '#select_header_content_type' do
196
+ let(:api_client) { GetAroundOwner::ApiClient.new }
197
+
198
+ it 'works' do
199
+ expect(api_client.select_header_content_type(nil)).to eq('application/json')
200
+ expect(api_client.select_header_content_type([])).to eq('application/json')
201
+
202
+ expect(api_client.select_header_content_type(['application/json'])).to eq('application/json')
203
+ expect(api_client.select_header_content_type(['application/xml', 'application/json; charset=UTF8'])).to eq('application/json; charset=UTF8')
204
+ expect(api_client.select_header_content_type(['APPLICATION/JSON', 'text/html'])).to eq('APPLICATION/JSON')
205
+ expect(api_client.select_header_content_type(['application/xml'])).to eq('application/xml')
206
+ expect(api_client.select_header_content_type(['text/plain', 'application/xml'])).to eq('text/plain')
207
+ end
208
+ end
209
+
210
+ describe '#sanitize_filename' do
211
+ let(:api_client) { GetAroundOwner::ApiClient.new }
212
+
213
+ it 'works' do
214
+ expect(api_client.sanitize_filename('sun')).to eq('sun')
215
+ expect(api_client.sanitize_filename('sun.gif')).to eq('sun.gif')
216
+ expect(api_client.sanitize_filename('../sun.gif')).to eq('sun.gif')
217
+ expect(api_client.sanitize_filename('/var/tmp/sun.gif')).to eq('sun.gif')
218
+ expect(api_client.sanitize_filename('./sun.gif')).to eq('sun.gif')
219
+ expect(api_client.sanitize_filename('..\sun.gif')).to eq('sun.gif')
220
+ expect(api_client.sanitize_filename('\var\tmp\sun.gif')).to eq('sun.gif')
221
+ expect(api_client.sanitize_filename('c:\var\tmp\sun.gif')).to eq('sun.gif')
222
+ expect(api_client.sanitize_filename('.\sun.gif')).to eq('sun.gif')
223
+ end
224
+ end
225
+ end