> ## 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 > Retrieves the list of existing driver agreements from the system for a particular fleet ID. ## OpenAPI ````yaml get /v2/driver-agreements/ 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/driver-agreements/: get: tags: - Driver-agreements summary: List Driver Agreements description: Retrieve all driver agreements associated with the provided Fleet-Id. operationId: listDriverAgreementsV2 parameters: - name: Fleet-Id in: header description: ID of the Fleet making the request. required: true schema: type: integer example: 123 responses: '200': description: Successful Response content: application/json: schema: type: array items: type: object properties: id: type: integer description: Unique identifier for the driver agreement. example: 5001 vehicle: type: object description: Vehicle associated with the driver agreement. properties: id: type: integer description: Unique vehicle ID. example: 10001 plate_number: type: string description: Vehicle license plate number. example: ABC1234 plate_state: type: string description: State of vehicle registration. example: TX vehicle_number: type: string description: Internal vehicle number or code. example: VEH001 vehicle_make: type: string description: Make/brand of the vehicle. example: Toyota vehicle_model: type: string description: Model of the vehicle. example: Corolla year: type: string description: Year of manufacture. example: '2023' lessee_renter: type: string nullable: true description: Name of the lessee or renter (if applicable). example: null custom_fields: type: object description: Custom vehicle fields. properties: Location: type: string description: Location where the vehicle is stationed. example: Warehouse A Equipment Number: type: string description: Internal equipment number. example: EQ-5567 vehicle_type_code: type: string nullable: true description: Code representing the vehicle type. example: SEDAN added_date: type: string format: date-time description: Date when the vehicle was added to the fleet. example: '2025-01-01T10:00:00Z' fleet: type: object description: Fleet details the vehicle belongs to. properties: id: type: integer description: Fleet ID. example: 10 title: type: string description: Name of the fleet. example: Demo Fleet region_details: type: array description: List of regions associated with the fleet. items: type: object properties: id: type: integer description: Region ID. example: 201 title: type: string description: Name of the region. example: Midwest is_active: type: boolean description: Whether the fleet is active. example: true billing_type: type: string description: >- Billing type for the fleet (e.g., PREPAID, POSTPAID). example: PREPAID onboarding_stage: type: string description: Stage of onboarding for the fleet. example: IN_PROGRESS warning_threshold_per_vehicle: type: integer nullable: true description: Warning threshold for fleet vehicles. example: null deactivation_threshold_per_vehicle: type: integer nullable: true description: Deactivation threshold for fleet vehicles. example: null client: type: string nullable: true description: Linked client account, if any. example: null onboarding_vehicle_order: type: integer description: Vehicle order number during onboarding. example: 15 active: type: boolean description: Whether the vehicle is active in the system. example: true agreement_status: type: string description: Current status of the agreement (e.g., ACTIVE, EXPIRED). example: ACTIVE agreement_start_date: type: string format: date-time description: Start date of the agreement. example: '2025-03-01T00:00:00Z' agreement_end_date: type: string format: date-time description: End date of the agreement. example: '2025-06-30T00:00:00Z' date_added: type: string format: date-time description: Date the agreement was added to the system. example: '2025-02-01T12:00:00Z' last_updated: type: string format: date-time description: Date the agreement was last updated. example: '2025-02-15T15:30:00Z' agreement_number: type: string description: Unique agreement number. example: AGMT-2025-001 driver: type: integer description: ID of the driver linked to this agreement. example: 3001 parent_agreement: type: string nullable: true description: ID of the parent agreement if this is a sub-agreement. example: null components: securitySchemes: bearerAuth: type: http scheme: bearer ````