> ## Documentation Index > Fetch the complete documentation index at: https://docs.fleetit.com/llms.txt > Use this file to discover all available pages before exploring further. # List ## OpenAPI ````yaml get /v2/integrations/active/ openapi: 3.0.0 info: title: FleetIT API V2 Public description: >- # Overview The Fleetit API is designed to provide developers with a streamlined and efficient way to interact with various fleet operations, including tolls, vehicles, and parking citations. This documentation provides a detailed overview of how to utilize this API effectively. # Error Codes The API will respond with specific error codes and messages to enable accurate troubleshooting. Common error codes include: ``` 200: Success 201: Created 304: Not Modified 400: Bad Request 401: Unauthorized 403: Forbidden 404: Not Found 500: Internal Server Error ``` # Multi-Fleets Management Our API supports the management of multiple fleets, allowing users to access and manipulate data specific to each fleet seamlessly. To ensure accurate data retrieval and manipulation across different fleets, users must specify their target fleet when making API requests. #### Specifying the Fleet in Requests To target a specific fleet, include the `Fleet-Id` header in your API requests. This header should carry the unique identifier (ID) of the fleet you wish to interact with. #### Header Format - **Header Name**: `Fleet-Id` - **Value**: The unique identifier (ID) of the fleet. Example of including the `Fleet-Id` header in a request: ``` Fleet-Id: ``` #### Default Fleet Data Retrieval If the `Fleet-Id` header is not included in a request, the API will automatically revert to the user's default fleet. Data associated with this default fleet will be fetched and returned in the response. This approach ensures that users can manage multiple fleets within the same system, providing flexibility and efficiency in accessing fleet-specific data. Always ensure that the `Fleet-Id` header is correctly specified to interact with the intended fleet. # Pagination Our API employs pagination to manage the retrieval of large datasets efficiently. Pagination is implemented through the use of `limit` and `offset` parameters in the GET request. This approach allows clients to control the number of records retrieved in a single response and to navigate through large sets of data incrementally. #### Parameters - **limit**: Specifies the maximum number of records to return in a single response. The maximum allowable value for this parameter is `100`. - **offset**: Indicates the starting position from which to return records. This parameter is used to skip a specified number of records from the beginning of the dataset. #### Usage To apply pagination, include the `limit` and `offset` parameters in your GET request query string. ##### Example Request ``` GET https://api.example.com/items?limit=20&offset=40 ``` This request would retrieve 20 records, starting from the 41st record (since the offset is 0-based). #### Limits The maximum limit for any endpoint is `100` records per request. Requests attempting to set a `limit` value greater than `100` will be automatically capped at `100`. #### Navigating Data Pages To navigate through datasets, adjust the `offset` parameter based on the `limit` value. For example, to retrieve the next set of records, increase the `offset` by the `limit` value used in the previous request. #### Best Practices - Use consistent `limit` values for sequential requests to ensure predictable pagination behavior. - Keep track of the `offset` and `limit` values to efficiently navigate back and forth within the dataset. Incorporating these pagination parameters in your API requests ensures efficient data retrieval and management, particularly when dealing with large volumes of data. version: 1.0.0 servers: - url: https://api.app.fleetit.com/ - url: https://api.staging.fleetit.com/ security: - bearerAuth: [] tags: - name: Auth - name: Auth > whoami - name: Vehicles - name: Fleet - name: Fleet > Settings - name: Fleet > ServiceTypes - name: Fleet > Regions - name: Parking - name: Transponders - name: Transponders > Shipments - name: Tolls - name: Integrations description: >- ### Welcome to FleetIT Integrations! Discover how to enhance your FleetIT experience by integrating with leading services such as Fleetio, Rent Centric, Webhook, and many more. Each integration enables streamlined workflows, data synchronization, and expanded capabilities tailored to your needs. #### Key Integration Highlights: - **Fleetio**: Automate the synchronization of vehicle data and manage expense entries effectively. [Required fields](https://fleetit.com/integrations/fleetio/) such as `License Plate`, `Ticket ID`, and `Transaction Date and Time` ensure detailed tracking. - **Rent Centric**: Ideal for rental operations, this integration allows seamless vehicle data management within FleetIT. - **Webhook**: Customize real-time data exchanges with Webhook to connect and automate your workflows across various platforms. For a detailed guide on how to set up and manage these integrations, including the specific fields required for each service and step-by-step instructions: ### [Visit Our Integrations Page](https://fleetit.com/integrations/) Leverage our comprehensive documentation to effortlessly integrate your systems, ensuring you make the most out of FleetIT's capabilities. For any assistance, our support team is ready to help you through the setup process and to answer any queries you might have. - name: Integrations > Webhook description: >- Our system sends webhook notifications to inform you of various events happening in real-time. This webhook mechanism allows you to receive updates directly to the URL you specify in your account settings. The following documentation outlines the structure of the webhook payload and how you can test and integrate it with your system. ### Webhook Headers To ensure secure and relevant communication, our webhook requests come with a set of HTTP headers: - **Fleet-Id**: This header uniquely identifies the fleet related to the event. It helps your system to verify the source and relevance of the incoming data. - **X-Signature**: The HMAC SHA-256 output as a hexadecimal string. - **X-Timestamp**: The timestamp when the signature was generated. - **ext-billing-id** and **ext-client-id,** to make it easier for billings. - **Custom Headers**: During the integration setup, you can configure additional custom headers. These headers will be included in every webhook notification sent to your endpoints. Custom headers can be used for additional security checks, such as signatures or specific tokens that your infrastructure requires for processing the incoming requests. # Security and Best Practices for Webhook Integration When integrating webhook notifications into your system, it's critical to implement robust security measures and follow best practices to ensure that the data transmitted is protected and handled efficiently. Here are some key security measures and best practices to consider: #### 1\. Use HTTPS for Endpoint Security Ensure that your endpoint is secured using HTTPS to encrypt data transmitted between our servers and your webhook endpoint. HTTPS prevents interception and tampering by third parties, ensuring that the data remains confidential and integral during transit. #### 2\. Duplicate Logic Handling Implement logic in your system to handle duplicate webhook calls. Webhooks may be sent more than once in some scenarios, such as network retries or duplicated processing logic. It's crucial to ensure that your system can identify and manage duplicate data, such as checking for unique event identifiers or timestamps before processing events. #### 3\. Securing Your Webhook When our service sends a webhook to your endpoint, it includes a signature in the `X-Signature` header. This signature is a hash, computed using HMAC SHA-256, of the payload concatenated with a timestamp. Steps to Verify the Signature **Step 1: Extract the Signature and Timestamp** Each webhook request will have the following headers: - `X-Signature`: The HMAC SHA-256 output as a hexadecimal string. - `X-Timestamp`: The timestamp when the signature was generated. **Step 2: Recreate the Payload String** Concatenate the `X-Timestamp` value and the raw request body with a dot (`.`) between them. The raw request body must be exactly as received, without any modifications or reformatting. **Step 3: Generate the Expected Signature** Using the secret key provided by us, perform an HMAC SHA-256 hash of the recreated payload string. Here is a sample code snippet in Python to illustrate this: ``` python import hmac import hashlib import json def verify_webhook_signature(received_signature: str, payload: dict, received_timestamp: int, secret_key: str): # Serialize the payload serialized_payload = json.dumps(payload, separators=(',', ':')) # Create the signed payload signed_payload = f"{received_timestamp}.{serialized_payload}" # Compute the HMAC SHA-256 hash expected_signature = hmac.new( secret_key.encode(), signed_payload.encode(), hashlib.sha256).hexdigest() # Use a constant-time comparison to compare the computed signature with the received signature return hmac.compare_digest(expected_signature, received_signature) ``` **Step 4: Compare the Signatures** Use a secure comparison function to compare the `expected_signature` with the `received_signature`. This comparison should be done using a constant-time algorithm to prevent timing attacks. - name: Integrations > Fleet Active Integrations - name: Integrations > Logs paths: /v2/integrations/active/: get: tags: - Integrations > Fleet Active Integrations summary: List parameters: - name: Fleet-ID in: header schema: type: integer example: '1' responses: '200': description: Successful response content: application/json: schema: type: object properties: count: type: integer next: type: string previous: type: string results: type: array items: type: object properties: id: type: integer integration: type: integer enabled: type: boolean data: type: object properties: auth: type: object additionalProperties: true urls: type: object additionalProperties: true config: type: object additionalProperties: true documentation: type: string documentation: type: string webhook_signature_secret_token: type: string example: count: 1 next: null previous: null results: - id: 121 integration: 4 enabled: true data: auth: url: >- https://webhook.site/1b064192-833f-41ff-99e0-a2e32044035f urls: {} config: {} documentation: >- https://docs.api.example.com/#9ca0ff12-d3d8-4339-b2a0-48b5477f3b62 documentation: >- https://docs.api.example.com/#9ca0ff12-d3d8-4339-b2a0-48b5477f3b62 webhook_signature_secret_token: dummy_token components: securitySchemes: bearerAuth: type: http scheme: bearer ````