### Zapier Integration Setup Source: https://docs.bouncie.dev/index Set up the Zapier integration by registering an application on the Bouncie Developer Portal and providing specific redirect URLs and credentials. ```APIDOC ## Zapier Integration Setup To use the Zapier integration, you will need to register an application on the Bouncie Developer Portal. Your application must have the following as a redirect URL: `https://zapier.com/dashboard/auth/oauth/return/App220583CLIAPI/` You will be prompted to provide the application's `Client ID` and `Client Secret` when connecting your account while creating a Zap with a Bouncie trigger. **This application should only be used with the Zapier integration.** ``` -------------------------------- ### Webhook Security Headers Source: https://docs.bouncie.dev/index Webhooks use Authorization and X-Bouncie-Authorization headers for security validation. These headers contain a unique key provided during application setup. The X-Bouncie-Authorization header is provided in case the platform removes the Authorization header. ```json { "Authorization": "yourKey", "X-Bouncie-Authorization": "yourKey" } ``` -------------------------------- ### FAQ - Duplicate Trip Events Source: https://docs.bouncie.dev/index Information on handling duplicate trip events, with a reference to the trip data documentation for detailed explanations and solutions. ```APIDOC ## FAQ - Duplicate Trip Events * See the trip data documentation for more details on why duplication happens and how to handle it properly in your application. ``` -------------------------------- ### FAQ - 401 Unauthorized Error Source: https://docs.bouncie.dev/index Troubleshoot 401 Unauthorized errors by checking access token validity, header formatting, and application permissions. ```APIDOC ## FAQ - 401 Unauthorized Error * The access token may be expired. See the request access tokens section for more information on how to generate a fresh access token. * The Authorization header value may not be formatted correctly. Make sure to only include the access token and **not** the "Bearer" prefix. * The application may no longer have access to the user data that the access token was issued for. Verify the user shows up in the list in the Users & Devices tab for the application on the Bouncie Developer Portal. ``` -------------------------------- ### Authorization API Source: https://docs.bouncie.dev/index Details on how to obtain authorization using OAuth 2.0, including the authorization code flow and obtaining access tokens. ```APIDOC ## Authorization API ### Description Bouncie API uses User Authentication with OAuth 2.0 to authorize users for your application. To obtain Authorization, you must first register your application on the Bouncie Developer Portal and follow the authorization code flow. ### Method GET ### Endpoint `https://auth.bouncie.com/dialog/authorize` ### Parameters #### Query Parameters - **client_id** (string) - Required - The Client ID obtained from the Bouncie Developer Portal. - **response_type** (string) - Required - Must be set to "code". - **redirect_uri** (string) - Required - The URI to redirect the user back to after granting permission. Must be pre-registered on the Bouncie Developer Portal. - **state** (string) - Optional - A value to maintain state and security during the redirect. ### Request Example ``` https://auth.bouncie.com/dialog/authorize?client_id=my-app&redirect_uri=http://www.example.com/&response_type=code&state=abcdefg ``` ### Response #### Success Response (Redirect) Upon user authorization, the user is redirected to the specified `redirect_uri` with the following query parameters: - **code** (string) - An authorization code that can be exchanged for an access token. This code expires if a new authorization code is generated for the same user and application. - **state** (string) - The value of the state parameter supplied in the request. #### Response Example ``` http://www.example.com/?code=I1uHE12LIK123PQRmnoGD1RnR12Ybrr99Tio1SQRpow12dabc&state=abcdefg ``` ``` -------------------------------- ### REST API Base URL Source: https://docs.bouncie.dev/index The base URL for all Bouncie REST API requests. ```APIDOC ## REST API Endpoints ### Base URL - The base URL is `https://api.bouncie.dev/v1/`. - All API requests must use HTTPS. - Successful requests return JSON data (`application/json`). ``` -------------------------------- ### Webhooks - Real-time Event Notifications Source: https://docs.bouncie.dev/index Configure webhooks to receive real-time notifications for events occurring on your vehicles. Bouncie will send POST requests with JSON payloads to your specified endpoint. ```APIDOC ## Webhooks ### Description Webhooks allow you to receive real-time notifications about events occurring on your vehicles. Configure a secure server-side URL endpoint on the Bouncie Developer Portal to receive event notifications. ### Configuration Provide a secure server-side URL endpoint and specify the event types you wish to receive. Bouncie will POST JSON event payloads to your endpoint when events occur. ### Security Webhooks are secured using a unique key. Bouncie includes an `Authorization` header and an `X-Bouncie-Authorization` header with every outgoing webhook. Both headers contain the same unique key for validation. #### Request Header Example ```json { "Authorization": "yourKey", "X-Bouncie-Authorization": "yourKey" } ``` ### Key Rotation To rotate your webhook key, return the new key in the `Authorization` response header when responding to a webhook. ### Retries Your webhook endpoint should respond with a `2xx` status code to indicate successful receipt. Bouncie will retry requests that time out, return invalid JSON, or respond with a `4xx` or `5xx` status code, using a backoff policy. ### Event Types - **Device** - Device Connected - Device Disconnected - VIN Change - **Vehicle Health** - MIL - Low Battery - **Trips** - Trip Start - Trip Data - Trip Metrics - Trip End - **Geo-Zones** - Application Geo-Zone - User Geo-Zone ``` -------------------------------- ### HTTP Headers for Authentication Source: https://docs.bouncie.dev/index This snippet shows the required HTTP headers for authenticating API requests. It includes the Authorization header with the generated access token and the Content-Type header set to application/json. ```json { "Authorization": "AccessTokenYouHaveGenerated", "Content-Type": "application/json" } ``` -------------------------------- ### FAQ - Webhook Data Volume Source: https://docs.bouncie.dev/index Understand factors influencing webhook data volume, including the number of devices, driving activity, subscribed events, and potential data spikes due to connectivity issues. ```APIDOC ## FAQ - Webhook Data Volume * Data volume depends on the number of devices authorized to your account and how often the vehicles they are installed in are driven. * The specific events you subscribe to play a significant role in overall data volume. For example: * `battery` events are sent only when battery voltage drops below a defined threshold. * `tripMetrics` is reported once per trip, upon its conclusion. * `tripData` events are transmitted continuously throughout the entirety of a trip and will make up the bulk of your data volume if enabled. * Devices may occasionally lose cellular connectivity — such as when operating in low-signal areas or parked underground. When this happens, trip data is temporarily stored on the device and transmitted once the connection is reestablished. Although the total volume of events remains unchanged, the data may be sent all at once over a short period of time. This can lead to brief spikes in webhook traffic. ``` -------------------------------- ### Request Access Token - POST Request Source: https://docs.bouncie.dev/index Exchange an authorization code for an access token by making a POST request to the Bouncie token endpoint. The request body must include client_id, client_secret, grant_type, code, and redirect_uri. Alternatively, client_id and client_secret can be sent as a base64 encoded string in the Authorization header. ```http POST https://auth.bouncie.com/oauth/token Content-Type: application/json { "client_id": "YOUR_CLIENT_ID", "client_secret": "YOUR_CLIENT_SECRET", "grant_type": "authorization_code", "code": "AUTHORIZATION_CODE", "redirect_uri": "YOUR_REDIRECT_URI" } ``` ```http POST https://auth.bouncie.com/oauth/token Content-Type: application/json Authorization: Basic BASE64_ENCODED_CLIENT_ID_CLIENT_SECRET { "grant_type": "authorization_code", "code": "AUTHORIZATION_CODE", "redirect_uri": "YOUR_REDIRECT_URI" } ``` -------------------------------- ### Authentication Source: https://docs.bouncie.dev/index The Bouncie API uses an access token granted per user for authentication. This token is generated when authorization is obtained. ```APIDOC ## Authentication The Bouncie API uses the access token that is granted to you per user who grants access to their information. This access token is generated when you obtain authorization. ### Request Headers ```json { "Authorization": "AccessTokenYouHaveGenerated", "Content-Type": "application/json" } ``` ``` -------------------------------- ### POST /oauth/token - Request Access Token Source: https://docs.bouncie.dev/index Exchange an authorization code for an access token. This token is required for making authenticated requests to the Bouncie API. ```APIDOC ## POST /oauth/token ### Description Exchanges an authorization code for an access token. This token is required for making authenticated requests to the Bouncie API. ### Method POST ### Endpoint https://auth.bouncie.com/oauth/token ### Parameters #### Header Parameters - **Content-Type** (string) - Required - Must be set to `application/json`. - **Authorization** (string) - Optional - If not sending `client_id` and `client_secret` in the body, send as a base64 encoded string: `Basic __`. #### Request Body - **client_id** (string) - Required - Your application's client ID. - **client_secret** (string) - Required - Your application's client secret. - **grant_type** (string) - Required - Must be set to `authorization_code`. - **code** (string) - Required - The authorization code received from the `/dialog/authorize` endpoint. - **redirect_uri** (string) - Required - Must match one of the Redirect URIs configured for your application. ### Request Example ```json { "client_id": "YOUR_CLIENT_ID", "client_secret": "YOUR_CLIENT_SECRET", "grant_type": "authorization_code", "code": "AUTHORIZATION_CODE", "redirect_uri": "YOUR_REDIRECT_URI" } ``` ### Response #### Success Response (200) - **access_token** (string) - An access token for authenticating API requests. - **token_type** (string) - The type of token, always "Bearer". - **expires_in** (int) - The validity period of the access token in seconds. #### Response Example ```json { "access_token": "ACCESS_TOKEN", "token_type": "Bearer", "expires_in": 3600 } ``` ``` -------------------------------- ### Application Geo-Zones Source: https://docs.bouncie.dev/index Application Geo-Zones are programmatically defined zones managed through the Bouncie API for integrations. They do not appear in the Bouncie client or trigger user notifications. ```APIDOC ## Application Geo-Zones Application Geo-Zones are designed for integrations that require programmatically defined zones. These zones are created and managed through the Bouncie API, allowing for dynamic setup and control independent of User Geo-Zones. Application Geo-Zones **do not appear** in the Bouncie client experience and do not trigger notifications to users. To create an Application Geo-Zone: 1. **Create a Location**: Define the geographic area by specifying coordinates and a radius or a polygon. Refer to the Create Location endpoint for details. 2. **(Optional) Create a Schedule**: Define active time periods for the geozone. This step is optional. Refer to the Create Schedule endpoint for details. 3. **Create the Application Geo-Zone**: Use the IDs from the Location and Schedule (if applicable) to create the geozone. Refer to the Create Application Geo-Zone endpoint for details. ``` -------------------------------- ### Responses and Errors Source: https://docs.bouncie.dev/index Bouncie API uses standard HTTP response codes to indicate success or failure of an API request. ```APIDOC ## Responses and Errors Bouncie API uses standard HTTP response codes to indicate success or failure of an API request. | Responses | Description | |---------------|-----------------------------------------------------------------------------| | 200 - OK | A GET request succeeded. JSON response. | | 201 - Created | A POST response succeeded. JSON response. | | 400 - Bad Request | The request was unacceptable, often due to missing a required parameter. JSON response `{"errors": "This was a bad request because..."}` | | 401 - Unauthorized | No valid API key provided. | | 404 - Not Found | The requested resource doesn't exist. | | 50x - Application Error | An error occurred on Bouncie API | ``` === COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.