> ## 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 > A viewset for listing and retrieving CustomerLog instances. with filtering capabilities. ## OpenAPI ````yaml get /v2/integrations/logs/ 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/logs/: get: tags: - Integrations > Logs summary: List parameters: - name: Fleet-ID in: header schema: type: integer example: '1' - name: integration in: query schema: type: string description: ID of the integration to filter example: '123' - name: success in: query schema: type: string description: Boolean example: 'true' - name: entity_type in: query schema: type: integer description: >- Where Choices Includes (1, Ticket), (2, Parking), (3, Violation), (4, Vehicle), (5, Transponder), (6, Authentication) example: '1' - name: integration_is_null in: query schema: type: string description: Boolean example: 'false' - name: timestamp_after in: query schema: type: string description: Date in YYYY-MM-DD format example: '2024-01-01' - name: timestamp_before in: query schema: type: string description: Date in YYYY-MM-DD format example: '2024-12-31' - name: entity_id in: query schema: type: string description: ID of the Entity you want to search for. e.g Ticket ID, Parking ID. example: '456' responses: '200': description: Successful response content: application/json: schema: type: object properties: count: type: integer description: Total number of matching logs example: 100 next: type: string description: URL to the next page of results example: >- http://api.app.fleetit.com/v2/integrations/logs/?limit=10&offset=10 previous: type: string description: URL to the previous page of results example: null results: type: array items: type: object properties: id: type: integer description: Unique identifier for the log entry example: 123456 integration: type: integer description: ID of the integration example: 49 timestamp: type: string description: Timestamp of the log entry example: '2024-05-05T21:09:01.685651-04:00' direction: type: string description: >- Direction of the log entry (e.g., Receiving, Sending) example: Receiving success: type: boolean description: Whether the integration was successful example: true response: type: object description: Response details from the integration properties: message: type: string description: Response message example: Success vehicles_updated: type: integer description: Number of vehicles updated example: 2 new_vehicles_added: type: integer description: Number of new vehicles added example: 0 unable_to_find_states: type: integer description: Number of states unable to find example: 0 total_vehicles_fetched: type: integer description: Total number of vehicles fetched example: 6178 belongs_to_different_fleet: type: integer description: >- Number of vehicles that belong to a different fleet example: 6176 details: type: object description: Additional details about the log entry properties: payload: type: object description: Payload that was sent additionalProperties: true error: type: string description: Error message, if any example: null entity_type: type: string description: Type of the entity (e.g., Vehicle, Ticket) example: Vehicle entity_id: type: string description: ID of the entity example: null example: count: 1 next: >- http://api.app.fleetit.com/v2/integrations/logs/?integration=123&limit=10&offset=10 previous: null results: - id: 123456 integration: 49 timestamp: '2024-05-05T21:09:01.685651-04:00' direction: Receiving success: true response: message: Success vehicles_updated: 2 new_vehicles_added: 0 unable_to_find_states: 0 total_vehicles_fetched: 6178 belongs_to_different_fleet: 6176 details: payload: null error: null entity_type: Vehicle entity_id: null components: securitySchemes: bearerAuth: type: http scheme: bearer ````