get_around_owner 1.0.6 → 1.0.8
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.
- checksums.yaml +4 -4
- data/README.md +4 -4
- data/get_around_owner-1.0.6.gem +0 -0
- data/get_around_owner-1.0.7.gem +0 -0
- data/lib/get_around_owner/api/checkins_api.rb +22 -7
- data/lib/get_around_owner/api/checkouts_api.rb +22 -7
- data/lib/get_around_owner/api/invoices_api.rb +24 -9
- data/lib/get_around_owner/api/messages_api.rb +44 -9
- data/lib/get_around_owner/api/payouts_api.rb +22 -7
- data/lib/get_around_owner/api/rentals_api.rb +22 -7
- data/lib/get_around_owner/api/unavailabilities_api.rb +44 -9
- data/lib/get_around_owner/version.rb +1 -1
- metadata +3 -1
checksums.yaml
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
SHA256:
|
|
3
|
-
metadata.gz:
|
|
4
|
-
data.tar.gz:
|
|
3
|
+
metadata.gz: 65f8a030784df3e7725858050ba0c109091b8866e147ffe01e6d75d05a7540ad
|
|
4
|
+
data.tar.gz: 4545088608d7c754fbf79b4907932fe307a56b8fb766061cb305ec3579debc54
|
|
5
5
|
SHA512:
|
|
6
|
-
metadata.gz:
|
|
7
|
-
data.tar.gz:
|
|
6
|
+
metadata.gz: 8cda383b491e422b915e06fcf8347673985e18ef26e1372815f0728af4ed264b3f0d2e43886633bf19abfc490701637640bf5370e1d9e46e59d50610037ea930
|
|
7
|
+
data.tar.gz: 617e53de49f3486b76d4aa82cdc458b369e505318f234f5e0fec8706c6010b6c2be84bff6528a2c1dfa8c840638f462f75764462d51b95b17b3dfa3584c0c9df
|
data/README.md
CHANGED
|
@@ -7,7 +7,7 @@ GetAroundOwner - the Ruby gem for the Getaround Owner API
|
|
|
7
7
|
This SDK is automatically generated by the [Swagger Codegen](https://github.com/swagger-api/swagger-codegen) project:
|
|
8
8
|
|
|
9
9
|
- API version: 1.0.0
|
|
10
|
-
- Package version: 1.0.
|
|
10
|
+
- Package version: 1.0.8
|
|
11
11
|
- Build package: io.swagger.codegen.v3.generators.ruby.RubyClientCodegen
|
|
12
12
|
|
|
13
13
|
## Installation
|
|
@@ -23,16 +23,16 @@ gem build get_around_owner.gemspec
|
|
|
23
23
|
Then either install the gem locally:
|
|
24
24
|
|
|
25
25
|
```shell
|
|
26
|
-
gem install ./get_around_owner-1.0.
|
|
26
|
+
gem install ./get_around_owner-1.0.8.gem
|
|
27
27
|
```
|
|
28
28
|
|
|
29
|
-
(for development, run `gem install --dev ./get_around_owner-1.0.
|
|
29
|
+
(for development, run `gem install --dev ./get_around_owner-1.0.8.gem` to install the development dependencies)
|
|
30
30
|
|
|
31
31
|
or publish the gem to a gem hosting service, e.g. [RubyGems](https://rubygems.org/).
|
|
32
32
|
|
|
33
33
|
Finally add this to the Gemfile:
|
|
34
34
|
|
|
35
|
-
gem 'get_around_owner', '~> 1.0.
|
|
35
|
+
gem 'get_around_owner', '~> 1.0.8'
|
|
36
36
|
|
|
37
37
|
### Install from Git
|
|
38
38
|
|
|
Binary file
|
|
Binary file
|
|
@@ -1,7 +1,7 @@
|
|
|
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
6
|
OpenAPI spec version: 1.0.0
|
|
7
7
|
Contact: owner-api@getaround.com
|
|
@@ -54,9 +54,9 @@ module GetAroundOwner
|
|
|
54
54
|
form_params = opts[:form_params] || {}
|
|
55
55
|
|
|
56
56
|
# http body (model)
|
|
57
|
-
post_body = opts[:body]
|
|
57
|
+
post_body = opts[:body]
|
|
58
58
|
|
|
59
|
-
return_type = opts[:return_type] || 'Checkin'
|
|
59
|
+
return_type = opts[:return_type] || 'Checkin'
|
|
60
60
|
|
|
61
61
|
auth_names = opts[:auth_names] || ['bearerAuth']
|
|
62
62
|
data, status_code, headers = @api_client.call_api(:GET, local_var_path,
|
|
@@ -81,8 +81,23 @@ module GetAroundOwner
|
|
|
81
81
|
# @option opts [] :per_page Page size (default to 30)
|
|
82
82
|
# @return [CheckinsIndex]
|
|
83
83
|
def get_checkins(start_date, end_date, opts = {})
|
|
84
|
-
|
|
85
|
-
|
|
84
|
+
# Don't specify a return type to get raw response
|
|
85
|
+
opts[:return_type] = nil
|
|
86
|
+
data, status_code, headers = get_checkins_with_http_info(start_date, end_date, opts)
|
|
87
|
+
|
|
88
|
+
if status_code == 200 && data
|
|
89
|
+
begin
|
|
90
|
+
# Parse JSON directly from response body
|
|
91
|
+
JSON.parse(data)
|
|
92
|
+
rescue JSON::ParserError => e
|
|
93
|
+
if @api_client.config.debugging
|
|
94
|
+
@api_client.config.logger.debug "Failed to parse JSON response: #{e.message}"
|
|
95
|
+
end
|
|
96
|
+
nil
|
|
97
|
+
end
|
|
98
|
+
else
|
|
99
|
+
nil
|
|
100
|
+
end
|
|
86
101
|
end
|
|
87
102
|
|
|
88
103
|
# List of checkins that occurred between two dates
|
|
@@ -124,9 +139,9 @@ module GetAroundOwner
|
|
|
124
139
|
form_params = opts[:form_params] || {}
|
|
125
140
|
|
|
126
141
|
# http body (model)
|
|
127
|
-
post_body = opts[:body]
|
|
142
|
+
post_body = opts[:body]
|
|
128
143
|
|
|
129
|
-
return_type = opts[:return_type] || 'CheckinsIndex'
|
|
144
|
+
return_type = opts[:return_type] || 'CheckinsIndex'
|
|
130
145
|
|
|
131
146
|
auth_names = opts[:auth_names] || ['bearerAuth']
|
|
132
147
|
data, status_code, headers = @api_client.call_api(:GET, local_var_path,
|
|
@@ -1,7 +1,7 @@
|
|
|
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
6
|
OpenAPI spec version: 1.0.0
|
|
7
7
|
Contact: owner-api@getaround.com
|
|
@@ -54,9 +54,9 @@ module GetAroundOwner
|
|
|
54
54
|
form_params = opts[:form_params] || {}
|
|
55
55
|
|
|
56
56
|
# http body (model)
|
|
57
|
-
post_body = opts[:body]
|
|
57
|
+
post_body = opts[:body]
|
|
58
58
|
|
|
59
|
-
return_type = opts[:return_type] || 'Checkout'
|
|
59
|
+
return_type = opts[:return_type] || 'Checkout'
|
|
60
60
|
|
|
61
61
|
auth_names = opts[:auth_names] || ['bearerAuth']
|
|
62
62
|
data, status_code, headers = @api_client.call_api(:GET, local_var_path,
|
|
@@ -81,8 +81,23 @@ module GetAroundOwner
|
|
|
81
81
|
# @option opts [] :per_page Page size (default to 30)
|
|
82
82
|
# @return [CheckoutsIndex]
|
|
83
83
|
def get_checkouts(start_date, end_date, opts = {})
|
|
84
|
-
|
|
85
|
-
|
|
84
|
+
# Don't specify a return type to get raw response
|
|
85
|
+
opts[:return_type] = nil
|
|
86
|
+
data, status_code, headers = get_checkouts_with_http_info(start_date, end_date, opts)
|
|
87
|
+
|
|
88
|
+
if status_code == 200 && data
|
|
89
|
+
begin
|
|
90
|
+
# Parse JSON directly from response body
|
|
91
|
+
JSON.parse(data)
|
|
92
|
+
rescue JSON::ParserError => e
|
|
93
|
+
if @api_client.config.debugging
|
|
94
|
+
@api_client.config.logger.debug "Failed to parse JSON response: #{e.message}"
|
|
95
|
+
end
|
|
96
|
+
nil
|
|
97
|
+
end
|
|
98
|
+
else
|
|
99
|
+
nil
|
|
100
|
+
end
|
|
86
101
|
end
|
|
87
102
|
|
|
88
103
|
# List of checkouts that occurred between two dates
|
|
@@ -124,9 +139,9 @@ module GetAroundOwner
|
|
|
124
139
|
form_params = opts[:form_params] || {}
|
|
125
140
|
|
|
126
141
|
# http body (model)
|
|
127
|
-
post_body = opts[:body]
|
|
142
|
+
post_body = opts[:body]
|
|
128
143
|
|
|
129
|
-
return_type = opts[:return_type] || 'CheckoutsIndex'
|
|
144
|
+
return_type = opts[:return_type] || 'CheckoutsIndex'
|
|
130
145
|
|
|
131
146
|
auth_names = opts[:auth_names] || ['bearerAuth']
|
|
132
147
|
data, status_code, headers = @api_client.call_api(:GET, local_var_path,
|
|
@@ -1,7 +1,7 @@
|
|
|
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
6
|
OpenAPI spec version: 1.0.0
|
|
7
7
|
Contact: owner-api@getaround.com
|
|
@@ -54,9 +54,9 @@ module GetAroundOwner
|
|
|
54
54
|
form_params = opts[:form_params] || {}
|
|
55
55
|
|
|
56
56
|
# http body (model)
|
|
57
|
-
post_body = opts[:body]
|
|
57
|
+
post_body = opts[:body]
|
|
58
58
|
|
|
59
|
-
return_type = opts[:return_type] || 'Invoice'
|
|
59
|
+
return_type = opts[:return_type] || 'Invoice'
|
|
60
60
|
|
|
61
61
|
auth_names = opts[:auth_names] || ['bearerAuth']
|
|
62
62
|
data, status_code, headers = @api_client.call_api(:GET, local_var_path,
|
|
@@ -81,8 +81,23 @@ module GetAroundOwner
|
|
|
81
81
|
# @option opts [] :per_page Page size (default to 30)
|
|
82
82
|
# @return [InvoicesIndex]
|
|
83
83
|
def get_invoices(opts = {})
|
|
84
|
-
|
|
85
|
-
|
|
84
|
+
# Don't specify a return type to get raw response
|
|
85
|
+
opts[:return_type] = nil
|
|
86
|
+
data, status_code, headers = get_invoices_with_http_info(opts)
|
|
87
|
+
|
|
88
|
+
if status_code == 200 && data
|
|
89
|
+
begin
|
|
90
|
+
# Parse JSON directly from response body
|
|
91
|
+
JSON.parse(data)
|
|
92
|
+
rescue JSON::ParserError => e
|
|
93
|
+
if @api_client.config.debugging
|
|
94
|
+
@api_client.config.logger.debug "Failed to parse JSON response: #{e.message}"
|
|
95
|
+
end
|
|
96
|
+
nil
|
|
97
|
+
end
|
|
98
|
+
else
|
|
99
|
+
nil
|
|
100
|
+
end
|
|
86
101
|
end
|
|
87
102
|
|
|
88
103
|
# Find invoices emitted between dates
|
|
@@ -116,9 +131,9 @@ module GetAroundOwner
|
|
|
116
131
|
form_params = opts[:form_params] || {}
|
|
117
132
|
|
|
118
133
|
# http body (model)
|
|
119
|
-
post_body = opts[:body]
|
|
134
|
+
post_body = opts[:body]
|
|
120
135
|
|
|
121
|
-
return_type = opts[:return_type] || 'InvoicesIndex'
|
|
136
|
+
return_type = opts[:return_type] || 'InvoicesIndex'
|
|
122
137
|
|
|
123
138
|
auth_names = opts[:auth_names] || ['bearerAuth']
|
|
124
139
|
data, status_code, headers = @api_client.call_api(:GET, local_var_path,
|
|
@@ -178,9 +193,9 @@ module GetAroundOwner
|
|
|
178
193
|
form_params = opts[:form_params] || {}
|
|
179
194
|
|
|
180
195
|
# http body (model)
|
|
181
|
-
post_body = opts[:body]
|
|
196
|
+
post_body = opts[:body]
|
|
182
197
|
|
|
183
|
-
return_type = opts[:return_type] || 'RentalInvoicesIndex'
|
|
198
|
+
return_type = opts[:return_type] || 'RentalInvoicesIndex'
|
|
184
199
|
|
|
185
200
|
auth_names = opts[:auth_names] || ['bearerAuth']
|
|
186
201
|
data, status_code, headers = @api_client.call_api(:GET, local_var_path,
|
|
@@ -1,7 +1,7 @@
|
|
|
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
6
|
OpenAPI spec version: 1.0.0
|
|
7
7
|
Contact: owner-api@getaround.com
|
|
@@ -58,9 +58,9 @@ module GetAroundOwner
|
|
|
58
58
|
form_params = opts[:form_params] || {}
|
|
59
59
|
|
|
60
60
|
# http body (model)
|
|
61
|
-
post_body = opts[:body] || @api_client.object_to_http_body(opts[:'body'])
|
|
61
|
+
post_body = opts[:body] || @api_client.object_to_http_body(opts[:'body'])
|
|
62
62
|
|
|
63
|
-
return_type = opts[:return_type] || 'Message'
|
|
63
|
+
return_type = opts[:return_type] || 'Message'
|
|
64
64
|
|
|
65
65
|
auth_names = opts[:auth_names] || ['bearerAuth']
|
|
66
66
|
data, status_code, headers = @api_client.call_api(:POST, local_var_path,
|
|
@@ -120,9 +120,9 @@ module GetAroundOwner
|
|
|
120
120
|
form_params = opts[:form_params] || {}
|
|
121
121
|
|
|
122
122
|
# http body (model)
|
|
123
|
-
post_body = opts[:body]
|
|
123
|
+
post_body = opts[:body]
|
|
124
124
|
|
|
125
|
-
return_type = opts[:return_type] || 'Message'
|
|
125
|
+
return_type = opts[:return_type] || 'Message'
|
|
126
126
|
|
|
127
127
|
auth_names = opts[:auth_names] || ['bearerAuth']
|
|
128
128
|
data, status_code, headers = @api_client.call_api(:GET, local_var_path,
|
|
@@ -144,8 +144,23 @@ module GetAroundOwner
|
|
|
144
144
|
# @param [Hash] opts the optional parameters
|
|
145
145
|
# @return [RentalMessagesIndex]
|
|
146
146
|
def get_messages_for_rental(rental_id, opts = {})
|
|
147
|
-
|
|
148
|
-
|
|
147
|
+
# Don't specify a return type to get raw response
|
|
148
|
+
opts[:return_type] = nil
|
|
149
|
+
data, status_code, headers = get_messages_for_rental_with_http_info(rental_id, opts)
|
|
150
|
+
|
|
151
|
+
if status_code == 200 && data
|
|
152
|
+
begin
|
|
153
|
+
# Parse JSON directly from response body
|
|
154
|
+
JSON.parse(data)
|
|
155
|
+
rescue JSON::ParserError => e
|
|
156
|
+
if @api_client.config.debugging
|
|
157
|
+
@api_client.config.logger.debug "Failed to parse JSON response: #{e.message}"
|
|
158
|
+
end
|
|
159
|
+
nil
|
|
160
|
+
end
|
|
161
|
+
else
|
|
162
|
+
nil
|
|
163
|
+
end
|
|
149
164
|
end
|
|
150
165
|
|
|
151
166
|
# Find messages associated to a rental
|
|
@@ -176,9 +191,9 @@ module GetAroundOwner
|
|
|
176
191
|
form_params = opts[:form_params] || {}
|
|
177
192
|
|
|
178
193
|
# http body (model)
|
|
179
|
-
post_body = opts[:body]
|
|
194
|
+
post_body = opts[:body]
|
|
180
195
|
|
|
181
|
-
return_type = opts[:return_type] || 'RentalMessagesIndex'
|
|
196
|
+
return_type = opts[:return_type] || 'RentalMessagesIndex'
|
|
182
197
|
|
|
183
198
|
auth_names = opts[:auth_names] || ['bearerAuth']
|
|
184
199
|
data, status_code, headers = @api_client.call_api(:GET, local_var_path,
|
|
@@ -194,5 +209,25 @@ module GetAroundOwner
|
|
|
194
209
|
end
|
|
195
210
|
return data, status_code, headers
|
|
196
211
|
end
|
|
212
|
+
|
|
213
|
+
def get_messages(opts = {})
|
|
214
|
+
# Don't specify a return type to get raw response
|
|
215
|
+
opts[:return_type] = nil
|
|
216
|
+
data, status_code, headers = get_messages_with_http_info(opts)
|
|
217
|
+
|
|
218
|
+
if status_code == 200 && data
|
|
219
|
+
begin
|
|
220
|
+
# Parse JSON directly from response body
|
|
221
|
+
JSON.parse(data)
|
|
222
|
+
rescue JSON::ParserError => e
|
|
223
|
+
if @api_client.config.debugging
|
|
224
|
+
@api_client.config.logger.debug "Failed to parse JSON response: #{e.message}"
|
|
225
|
+
end
|
|
226
|
+
nil
|
|
227
|
+
end
|
|
228
|
+
else
|
|
229
|
+
nil
|
|
230
|
+
end
|
|
231
|
+
end
|
|
197
232
|
end
|
|
198
233
|
end
|
|
@@ -1,7 +1,7 @@
|
|
|
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
6
|
OpenAPI spec version: 1.0.0
|
|
7
7
|
Contact: owner-api@getaround.com
|
|
@@ -54,9 +54,9 @@ module GetAroundOwner
|
|
|
54
54
|
form_params = opts[:form_params] || {}
|
|
55
55
|
|
|
56
56
|
# http body (model)
|
|
57
|
-
post_body = opts[:body]
|
|
57
|
+
post_body = opts[:body]
|
|
58
58
|
|
|
59
|
-
return_type = opts[:return_type] || 'Payout'
|
|
59
|
+
return_type = opts[:return_type] || 'Payout'
|
|
60
60
|
|
|
61
61
|
auth_names = opts[:auth_names] || ['bearerAuth']
|
|
62
62
|
data, status_code, headers = @api_client.call_api(:GET, local_var_path,
|
|
@@ -81,8 +81,23 @@ module GetAroundOwner
|
|
|
81
81
|
# @option opts [] :per_page Page size (default to 30)
|
|
82
82
|
# @return [PayoutsIndex]
|
|
83
83
|
def get_payouts(start_date, end_date, opts = {})
|
|
84
|
-
|
|
85
|
-
|
|
84
|
+
# Don't specify a return type to get raw response
|
|
85
|
+
opts[:return_type] = nil
|
|
86
|
+
data, status_code, headers = get_payouts_with_http_info(start_date, end_date, opts)
|
|
87
|
+
|
|
88
|
+
if status_code == 200 && data
|
|
89
|
+
begin
|
|
90
|
+
# Parse JSON directly from response body
|
|
91
|
+
JSON.parse(data)
|
|
92
|
+
rescue JSON::ParserError => e
|
|
93
|
+
if @api_client.config.debugging
|
|
94
|
+
@api_client.config.logger.debug "Failed to parse JSON response: #{e.message}"
|
|
95
|
+
end
|
|
96
|
+
nil
|
|
97
|
+
end
|
|
98
|
+
else
|
|
99
|
+
nil
|
|
100
|
+
end
|
|
86
101
|
end
|
|
87
102
|
|
|
88
103
|
# Find payouts paid between dates
|
|
@@ -124,9 +139,9 @@ module GetAroundOwner
|
|
|
124
139
|
form_params = opts[:form_params] || {}
|
|
125
140
|
|
|
126
141
|
# http body (model)
|
|
127
|
-
post_body = opts[:body]
|
|
142
|
+
post_body = opts[:body]
|
|
128
143
|
|
|
129
|
-
return_type = opts[:return_type] || 'PayoutsIndex'
|
|
144
|
+
return_type = opts[:return_type] || 'PayoutsIndex'
|
|
130
145
|
|
|
131
146
|
auth_names = opts[:auth_names] || ['bearerAuth']
|
|
132
147
|
data, status_code, headers = @api_client.call_api(:GET, local_var_path,
|
|
@@ -1,7 +1,7 @@
|
|
|
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
6
|
OpenAPI spec version: 1.0.0
|
|
7
7
|
Contact: owner-api@getaround.com
|
|
@@ -54,9 +54,9 @@ module GetAroundOwner
|
|
|
54
54
|
form_params = opts[:form_params] || {}
|
|
55
55
|
|
|
56
56
|
# http body (model)
|
|
57
|
-
post_body = opts[:body]
|
|
57
|
+
post_body = opts[:body]
|
|
58
58
|
|
|
59
|
-
return_type = opts[:return_type] || 'Rental'
|
|
59
|
+
return_type = opts[:return_type] || 'Rental'
|
|
60
60
|
|
|
61
61
|
auth_names = opts[:auth_names] || ['bearerAuth']
|
|
62
62
|
data, status_code, headers = @api_client.call_api(:GET, local_var_path,
|
|
@@ -81,8 +81,23 @@ module GetAroundOwner
|
|
|
81
81
|
# @option opts [] :per_page Page size (default to 30)
|
|
82
82
|
# @return [RentalsIndex]
|
|
83
83
|
def get_rentals(start_date, end_date, opts = {})
|
|
84
|
-
|
|
85
|
-
|
|
84
|
+
# Don't specify a return type to get raw response
|
|
85
|
+
opts[:return_type] = nil
|
|
86
|
+
data, status_code, headers = get_rentals_with_http_info(start_date, end_date, opts)
|
|
87
|
+
|
|
88
|
+
if status_code == 200 && data
|
|
89
|
+
begin
|
|
90
|
+
# Parse JSON directly from response body
|
|
91
|
+
JSON.parse(data)
|
|
92
|
+
rescue JSON::ParserError => e
|
|
93
|
+
if @api_client.config.debugging
|
|
94
|
+
@api_client.config.logger.debug "Failed to parse JSON response: #{e.message}"
|
|
95
|
+
end
|
|
96
|
+
nil
|
|
97
|
+
end
|
|
98
|
+
else
|
|
99
|
+
nil
|
|
100
|
+
end
|
|
86
101
|
end
|
|
87
102
|
|
|
88
103
|
# Find rentals booked between dates
|
|
@@ -124,9 +139,9 @@ module GetAroundOwner
|
|
|
124
139
|
form_params = opts[:form_params] || {}
|
|
125
140
|
|
|
126
141
|
# http body (model)
|
|
127
|
-
post_body = opts[:body]
|
|
142
|
+
post_body = opts[:body]
|
|
128
143
|
|
|
129
|
-
return_type = opts[:return_type] || 'RentalsIndex'
|
|
144
|
+
return_type = opts[:return_type] || 'RentalsIndex'
|
|
130
145
|
|
|
131
146
|
auth_names = opts[:auth_names] || ['bearerAuth']
|
|
132
147
|
data, status_code, headers = @api_client.call_api(:GET, local_var_path,
|
|
@@ -1,7 +1,7 @@
|
|
|
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
6
|
OpenAPI spec version: 1.0.0
|
|
7
7
|
Contact: owner-api@getaround.com
|
|
@@ -56,9 +56,9 @@ module GetAroundOwner
|
|
|
56
56
|
form_params = opts[:form_params] || {}
|
|
57
57
|
|
|
58
58
|
# http body (model)
|
|
59
|
-
post_body = opts[:body] || @api_client.object_to_http_body(opts[:'body'])
|
|
59
|
+
post_body = opts[:body] || @api_client.object_to_http_body(opts[:'body'])
|
|
60
60
|
|
|
61
|
-
return_type = opts[:return_type]
|
|
61
|
+
return_type = opts[:return_type]
|
|
62
62
|
|
|
63
63
|
auth_names = opts[:auth_names] || ['bearerAuth']
|
|
64
64
|
data, status_code, headers = @api_client.call_api(:POST, local_var_path,
|
|
@@ -110,9 +110,9 @@ module GetAroundOwner
|
|
|
110
110
|
form_params = opts[:form_params] || {}
|
|
111
111
|
|
|
112
112
|
# http body (model)
|
|
113
|
-
post_body = opts[:body]
|
|
113
|
+
post_body = opts[:body]
|
|
114
114
|
|
|
115
|
-
return_type = opts[:return_type]
|
|
115
|
+
return_type = opts[:return_type]
|
|
116
116
|
|
|
117
117
|
auth_names = opts[:auth_names] || ['bearerAuth']
|
|
118
118
|
data, status_code, headers = @api_client.call_api(:DELETE, local_var_path,
|
|
@@ -138,8 +138,23 @@ module GetAroundOwner
|
|
|
138
138
|
# @option opts [] :per_page Page size (default to 30)
|
|
139
139
|
# @return [UnavailabilitiesIndex]
|
|
140
140
|
def get_unavailabilities_for_car(start_date, end_date, car_id, opts = {})
|
|
141
|
-
|
|
142
|
-
|
|
141
|
+
# Don't specify a return type to get raw response
|
|
142
|
+
opts[:return_type] = nil
|
|
143
|
+
data, status_code, headers = get_unavailabilities_for_car_with_http_info(start_date, end_date, car_id, opts)
|
|
144
|
+
|
|
145
|
+
if status_code == 200 && data
|
|
146
|
+
begin
|
|
147
|
+
# Parse JSON directly from response body
|
|
148
|
+
JSON.parse(data)
|
|
149
|
+
rescue JSON::ParserError => e
|
|
150
|
+
if @api_client.config.debugging
|
|
151
|
+
@api_client.config.logger.debug "Failed to parse JSON response: #{e.message}"
|
|
152
|
+
end
|
|
153
|
+
nil
|
|
154
|
+
end
|
|
155
|
+
else
|
|
156
|
+
nil
|
|
157
|
+
end
|
|
143
158
|
end
|
|
144
159
|
|
|
145
160
|
# Find Unavailabilities related to a car between dates
|
|
@@ -186,9 +201,9 @@ module GetAroundOwner
|
|
|
186
201
|
form_params = opts[:form_params] || {}
|
|
187
202
|
|
|
188
203
|
# http body (model)
|
|
189
|
-
post_body = opts[:body]
|
|
204
|
+
post_body = opts[:body]
|
|
190
205
|
|
|
191
|
-
return_type = opts[:return_type] || 'UnavailabilitiesIndex'
|
|
206
|
+
return_type = opts[:return_type] || 'UnavailabilitiesIndex'
|
|
192
207
|
|
|
193
208
|
auth_names = opts[:auth_names] || ['bearerAuth']
|
|
194
209
|
data, status_code, headers = @api_client.call_api(:GET, local_var_path,
|
|
@@ -204,5 +219,25 @@ module GetAroundOwner
|
|
|
204
219
|
end
|
|
205
220
|
return data, status_code, headers
|
|
206
221
|
end
|
|
222
|
+
|
|
223
|
+
def get_unavailabilities(opts = {})
|
|
224
|
+
# Don't specify a return type to get raw response
|
|
225
|
+
opts[:return_type] = nil
|
|
226
|
+
data, status_code, headers = get_unavailabilities_with_http_info(opts)
|
|
227
|
+
|
|
228
|
+
if status_code == 200 && data
|
|
229
|
+
begin
|
|
230
|
+
# Parse JSON directly from response body
|
|
231
|
+
JSON.parse(data)
|
|
232
|
+
rescue JSON::ParserError => e
|
|
233
|
+
if @api_client.config.debugging
|
|
234
|
+
@api_client.config.logger.debug "Failed to parse JSON response: #{e.message}"
|
|
235
|
+
end
|
|
236
|
+
nil
|
|
237
|
+
end
|
|
238
|
+
else
|
|
239
|
+
nil
|
|
240
|
+
end
|
|
241
|
+
end
|
|
207
242
|
end
|
|
208
243
|
end
|
metadata
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
|
2
2
|
name: get_around_owner
|
|
3
3
|
version: !ruby/object:Gem::Version
|
|
4
|
-
version: 1.0.
|
|
4
|
+
version: 1.0.8
|
|
5
5
|
platform: ruby
|
|
6
6
|
authors:
|
|
7
7
|
- OpenAPI-Generator
|
|
@@ -219,6 +219,8 @@ files:
|
|
|
219
219
|
- get_around_owner-1.0.3.gem
|
|
220
220
|
- get_around_owner-1.0.4.gem
|
|
221
221
|
- get_around_owner-1.0.5.gem
|
|
222
|
+
- get_around_owner-1.0.6.gem
|
|
223
|
+
- get_around_owner-1.0.7.gem
|
|
222
224
|
- get_around_owner.gemspec
|
|
223
225
|
- getaround-api.gemspec
|
|
224
226
|
- git_push.sh
|