# Obtain Token Source: https://docs.fleetit.com/api-reference/auth/obtain-token post /api/auth/token/ Exchange credentials for an access token. # Refresh Token Source: https://docs.fleetit.com/api-reference/auth/refresh-token post /api/auth/token/refresh/ Exchange a refresh token for a new access token. The request requires a valid refresh token to be present in the cookie named `refresh_token` # Update Source: https://docs.fleetit.com/api-reference/auth/whoami/update put /v2/whoami/ This API endpoint allows you to update the user information. # Whoami Source: https://docs.fleetit.com/api-reference/auth/whoami/whoami get /v2/whoami/ This endpoint allows you to retrieve information about the currently authenticated user. # Get Source: https://docs.fleetit.com/api-reference/documents/get get /document/{id}/ Retrieve a single document by ID. # List Source: https://docs.fleetit.com/api-reference/documents/list get /document/ Retrieve a paginated list of uploaded documents. # Upload Source: https://docs.fleetit.com/api-reference/documents/upload post /document/upload/ Upload a single PDF document. # Upload Multiple Source: https://docs.fleetit.com/api-reference/documents/upload-multi post /document/upload/multi/ Upload multiple PDF documents in a single request. # Add Source: https://docs.fleetit.com/api-reference/driver-agreements/add post /v2/driver-agreements/ Creates a single driver agreement based on a particular vehicle and driver . # Close Source: https://docs.fleetit.com/api-reference/driver-agreements/close post /v2/driver-agreements/{id}/close/ Closes an existing driver agreement by setting the agreement end date. ## Request Format The request payload should include the `agreement_end_date` in ISO 8601 format: ```json theme={null} { "agreement_end_date": "2025-08-30T18:37:34.000Z" } ``` ### Date Format The `agreement_end_date` should be provided in ISO 8601 format: `YYYY-MM-DDTHH:mm:ss.sssZ` Example: `2025-08-30T18:37:34.000Z` # Bulk Create Source: https://docs.fleetit.com/api-reference/driver-agreements/create-bulk post /v2/driver-agreements/bulk/ Creates multiple driver agreements based on provided vehicle and driver details. # Exchange Source: https://docs.fleetit.com/api-reference/driver-agreements/exchange post /v2/driver-agreements/{id}/exchange/ Exchange an existing driver agreement for a new driver. # Get Driver Agreement Source: https://docs.fleetit.com/api-reference/driver-agreements/get get /v2/driver-agreements/{id}/ Retrieve a driver agreement by ID. # List Source: https://docs.fleetit.com/api-reference/driver-agreements/list get /v2/driver-agreements/ Retrieves the list of existing driver agreements from the system for a particular fleet ID. # Update Driver Agreement Source: https://docs.fleetit.com/api-reference/driver-agreements/update patch /v2/driver-agreements/{id}/ Partially update a driver agreement by ID. # Create Credit Note Source: https://docs.fleetit.com/api-reference/driver-credit-notes/create post /v2/driver-credit-notes/ Create a credit note. Credit notes are normally created against a finalized invoice via [Create Credit Note](/api-reference/driver-invoices/create-credit-note) on the invoice. # Download Credit Note PDF Source: https://docs.fleetit.com/api-reference/driver-credit-notes/download get /v2/driver-credit-notes/{id}/download/ Retrieve the credit-note PDF (async; poll until ready). Same polling contract as the invoice download: `202` with `{"detail": "PDF is being generated."}` while pending, `200` with `{"url": "https://…"}` once `pdf_status` is `COMPLETE`. # Get Credit Note Source: https://docs.fleetit.com/api-reference/driver-credit-notes/get get /v2/driver-credit-notes/{id}/ Retrieve a single credit note. # List Credit Notes Source: https://docs.fleetit.com/api-reference/driver-credit-notes/list get /v2/driver-credit-notes/ Retrieve all credit notes. # Void Credit Note Source: https://docs.fleetit.com/api-reference/driver-credit-notes/void post /v2/driver-credit-notes/{id}/void/ Void a credit note. No body. Sets `status` to `VOID` and stamps `voided_at`. # Adjust Fee Source: https://docs.fleetit.com/api-reference/driver-invoices/adjust-fee put /v2/driver-invoices/{id}/adjust-fee/ Override a charge line on a draft invoice. Only valid on a `DRAFT` invoice. Body: ```json theme={null} { "charge_snapshot_index": 0, "override_quantity": "8.00", "override_unit_amount": "1.25", "reason": "Corrected count" } ``` `charge_snapshot_index` is the 0-based index into `plan_snapshot.charges`. At least one of `override_quantity` / `override_unit_amount` is required. Returns the adjustment (`201` new, `200` updated) with the original values preserved. # Create Driver Invoice Source: https://docs.fleetit.com/api-reference/driver-invoices/create post /v2/driver-invoices/ Create a driver invoice. # Create Credit Note Source: https://docs.fleetit.com/api-reference/driver-invoices/create-credit-note post /v2/driver-invoices/{id}/credit-notes/ Credit against a finalized invoice. Only against a `FINALIZED` invoice; total must be > 0 and ≤ the invoice balance. Body: ```json theme={null} { "reason": "billing_error", "notes": "optional", "items": [ { "fee_id": 1, "description": "Refund toll", "amount": "10.00" } ], "attachments": [ { "type": "tolls", "id": 55 } ] } ``` `reason` ∈ `duplicated_charge`, `billing_error`, `dispute`, `goodwill`, `other`. `fee_id` (optional) must reference a fee on that invoice. `attachments[].type` ∈ `tolls`, `citations`. Returns `201`; the PDF is generated asynchronously. # Delete Driver Invoice Source: https://docs.fleetit.com/api-reference/driver-invoices/delete delete /v2/driver-invoices/{id}/ Delete a driver invoice. # Download Invoice PDF Source: https://docs.fleetit.com/api-reference/driver-invoices/download get /v2/driver-invoices/{id}/download/ Retrieve the invoice PDF (async; poll until ready). PDFs are generated asynchronously. This action triggers generation on the first call, so it is the safe entry point. | `pdf_status` | HTTP | Body | | ---------------------------------- | ----- | ---------------------------------------------------- | | `null` / `PENDING` / `IN_PROGRESS` | `202` | `{"detail": "PDF is being generated."}` — poll again | | `COMPLETE` | `200` | `{"url": "https://…"}` — fetch the file at `url` | The `url` is a time-limited storage URL. # Export Invoices to CSV Source: https://docs.fleetit.com/api-reference/driver-invoices/export get /v2/driver-invoices/export/ Email a CSV export of invoices matching the current filters. `GET /v2/driver-invoices/export/?channel=email[&email=
]` * `channel` **must** be `email`; any other value returns `400`. * `email` (optional) must belong to the caller's fleet or be the caller's own address, else `404`. Defaults to the authenticated user's email. * All list filters (status, driver, date range, …) are honored. Returns `200` immediately. The CSVs (invoices, fees, tickets) are generated in the background and emailed — not returned in the response. # Finalize Invoice Source: https://docs.fleetit.com/api-reference/driver-invoices/finalize post /v2/driver-invoices/{id}/finalize/ Lock the invoice and trigger PDF generation. Sets `status` to `FINALIZED`, freezes `total`, and enqueues PDF generation. Retrieve the PDF via the [download](/api-reference/driver-invoices/download) action. # Generate Draft Invoice Source: https://docs.fleetit.com/api-reference/driver-invoices/generate post /v2/driver-invoices/generate/ Create a draft invoice for an agreement. Body: `{"agreement_id": 77}`. Returns `201` with the invoice, or `200` with `{"detail": "No unbilled tickets found for this agreement."}` when there is nothing to bill. # Get Driver Invoice Source: https://docs.fleetit.com/api-reference/driver-invoices/get get /v2/driver-invoices/{id}/ Retrieve a single driver invoice with fees, tickets, and adjustments. # List Driver Invoices Source: https://docs.fleetit.com/api-reference/driver-invoices/list get /v2/driver-invoices/ Retrieve all driver invoices. Ordered newest-first; archived invoices are excluded. List items are lightweight (`DriverInvoiceListSerializer`) — no fees or tickets; fetch a single invoice for those. **Filters** | Param | Meaning | | --------------------------------------- | ------------------------------------------------------------ | | `status` | `DRAFT`, `FINALIZED`, `VOID` | | `trigger` | `PROGRESSIVE`, `AGREEMENT_ENDED`, `LATE_TICKET`, `MANUAL` | | `driver` | driver id | | `agreement` | agreement id | | `created_at_after`, `created_at_before` | date range on `created_at` | | `total_min`, `total_max` | numeric total range (falls back to draft total) | | `overdue` | boolean; unpaid and past due date | | `search` | matches invoice number, driver name, plate, agreement number | # Update Payment Status Source: https://docs.fleetit.com/api-reference/driver-invoices/payment-status post /v2/driver-invoices/{id}/payment-status/ Set the payment status of an invoice. Body: `{"payment_status": "SUCCEEDED"}` — one of `PENDING`, `SUCCEEDED`, `FAILED`. Returns the updated invoice. # Preview Draft Total Source: https://docs.fleetit.com/api-reference/driver-invoices/preview get /v2/driver-invoices/{id}/preview/ Return the draft total without saving. Computes and returns the current draft total for a `DRAFT` invoice without persisting changes. Rarely used in practice — [refresh](/api-reference/driver-invoices/refresh) is the usual way to recompute a draft. # Refresh Draft Invoice Source: https://docs.fleetit.com/api-reference/driver-invoices/refresh post /v2/driver-invoices/{id}/refresh/ Recalculate a draft invoice and pull in unbilled tickets. Recalculates the fees on a `DRAFT` invoice and pulls in any unbilled tickets. Typically called just before finalizing. # Remove Fee Adjustment Source: https://docs.fleetit.com/api-reference/driver-invoices/remove-adjustment delete /v2/driver-invoices/{id}/adjust-fee/{charge_index}/ Drop a fee override from a draft invoice. `charge_index` is the `charge_snapshot_index` of the adjustment to remove. The fee reverts to its computed values. # Update Driver Invoice Source: https://docs.fleetit.com/api-reference/driver-invoices/update put /v2/driver-invoices/{id}/ Update a driver invoice. # Void Invoice Source: https://docs.fleetit.com/api-reference/driver-invoices/void post /v2/driver-invoices/{id}/void/ Void an invoice, optionally releasing its tickets. Body: `{"release_tickets": false}` (optional, default `false`). When `true`, the invoice's tickets are released back to the unbilled pool so they can be billed again. # Add Source: https://docs.fleetit.com/api-reference/drivers/add post /v2/drivers/ Driver Model View Set # Get Driver Source: https://docs.fleetit.com/api-reference/drivers/get get /v2/drivers/{id}/ Retrieve a driver by ID. # List Source: https://docs.fleetit.com/api-reference/drivers/list get /v2/drivers/ List the existing drivers in the system # Create Source: https://docs.fleetit.com/api-reference/fleet/create post /v2/fleets/ Create a fleet in the system. # Get Source: https://docs.fleetit.com/api-reference/fleet/get get /v2/fleets/{id}/ Get a fleet by ID. # List Source: https://docs.fleetit.com/api-reference/fleet/list get /v2/fleets/ Retrieve a list of all fleets in the system. # Create Onboarding Vehicles Source: https://docs.fleetit.com/api-reference/fleet/onboarding/create-vehicles post /v2/fleets/onboarding/vehicles/ Submit vehicles for fleet onboarding. # List Onboarding Vehicles Source: https://docs.fleetit.com/api-reference/fleet/onboarding/list-vehicles get /v2/fleets/onboarding/vehicles/ Retrieve vehicles for fleet onboarding. # Patch Fleet Source: https://docs.fleetit.com/api-reference/fleet/patch patch /v2/fleets/{id}/ Partially update a fleet by ID. # List Source: https://docs.fleetit.com/api-reference/fleet/regions/list get /api/regions/ Retrieve a list of all regions in the system. Deprecated — will be removed soon. Use the v2 equivalent. # Get Service Type Source: https://docs.fleetit.com/api-reference/fleet/servicetypes/get get /v2/service_types/{id}/ Retrieve a service type by ID. # List Source: https://docs.fleetit.com/api-reference/fleet/servicetypes/list get /v2/service_types/ Retrieve a list of all service types in the system. # Get Source: https://docs.fleetit.com/api-reference/fleet/settings/get get /v2/fleet/settings/ Retrieve the settings of the fleet. # Patch Settings Source: https://docs.fleetit.com/api-reference/fleet/settings/patch patch /v2/fleet/settings/ Partially update fleet settings. # Update Source: https://docs.fleetit.com/api-reference/fleet/settings/update put /v2/fleet/settings/ Update the settings of the fleet. # Update Source: https://docs.fleetit.com/api-reference/fleet/update put /v2/fleets/{id}/ Update a fleet by ID. # Create Source: https://docs.fleetit.com/api-reference/integrations/fleet-active-integrations/create post /v2/integrations/active/ # Delete Active Integration Source: https://docs.fleetit.com/api-reference/integrations/fleet-active-integrations/delete delete /v2/integrations/active/{id}/ Delete an active fleet integration. # Get Source: https://docs.fleetit.com/api-reference/integrations/fleet-active-integrations/get get /v2/integrations/active/{id}/ # List Source: https://docs.fleetit.com/api-reference/integrations/fleet-active-integrations/list get /v2/integrations/active/ # Update Source: https://docs.fleetit.com/api-reference/integrations/fleet-active-integrations/update put /v2/integrations/active/{id}/ # Get Integration Source: https://docs.fleetit.com/api-reference/integrations/get get /v2/integrations/{id}/ Retrieve an integration by ID. # List Source: https://docs.fleetit.com/api-reference/integrations/list get /v2/integrations/ Retrieve a list of all integrations in the system. # Get Integration Log Source: https://docs.fleetit.com/api-reference/integrations/logs/get get /v2/integrations/logs/{id}/ Retrieve an integration log by ID. # List Source: https://docs.fleetit.com/api-reference/integrations/logs/list get /v2/integrations/logs/ A viewset for listing and retrieving CustomerLog instances. with filtering capabilities. # Columns Source: https://docs.fleetit.com/api-reference/parking/columns get /v2/citations/columns/ # Get Citation Source: https://docs.fleetit.com/api-reference/parking/get get /v2/citations/{id}/ Retrieve details for a specific citation. The `ticket_type` field in the response shows the display name (e.g., "Parking", "Bus Camera") rather than the numeric ID. # List Source: https://docs.fleetit.com/api-reference/parking/list get /v2/citations/ Retrieve a list of all citations in the system. ## Ticket Type Field The `ticket_type` field represents the category of traffic violation: | ID | Display Name | Description | | -- | ---------------- | --------------------------------------- | | 1 | Bus Camera | Bus lane violations captured by camera | | 2 | Parking | Parking violations and tickets | | 3 | Red Light Camera | Red light violations captured by camera | | 4 | Speed Camera | Speed violations captured by camera | | 5 | Other | Other types of traffic violations | | 6 | Idling | Vehicle idling violations | ### Filtering by Ticket Type Use the numeric ID when filtering: ``` GET /v2/citations?ticket_type=2 # Filter for Parking violations GET /v2/citations?ticket_type=1 # Filter for Bus Camera violations ``` When filtering, use the numeric ID (1-6). The API response returns the display name (e.g., "Parking", "Bus Camera"). # Summary Source: https://docs.fleetit.com/api-reference/parking/summary get /v2/citations/summary/ Get summary statistics for citations. When filtering by `ticket_type`, use numeric IDs: 1 (Bus Camera), 2 (Parking), 3 (Red Light Camera), 4 (Speed Camera), 5 (Other), 6 (Idling). # Get Toll Source: https://docs.fleetit.com/api-reference/tolls/get get /v2/tolls/{id}/ Retrieve a toll by ID. # History Source: https://docs.fleetit.com/api-reference/tolls/history get /v2/tolls/{id}/history/ Retrieve the history of a toll. # List Source: https://docs.fleetit.com/api-reference/tolls/list get /v2/tolls/ Returns a list of tolls. # Update Toll Source: https://docs.fleetit.com/api-reference/tolls/update patch /v2/tolls/{id}/ Partially update a toll by ID. # Assign Vehicle Source: https://docs.fleetit.com/api-reference/transponders/assign-vehicle put /v2/transponders/{id}/vehicle/ Assign a vehicle to a transponder # Create Order Source: https://docs.fleetit.com/api-reference/transponders/create-order post /v2/transponders/create-order/ Create a transponder order. # GET Source: https://docs.fleetit.com/api-reference/transponders/get get /v2/transponders/{id}/ Retrieve a transponder by ID # List Source: https://docs.fleetit.com/api-reference/transponders/list get /v2/transponders/ Retrieve a list of transponders # Ship Source: https://docs.fleetit.com/api-reference/transponders/shipments/confirm-shipment post /v2/transponders/shipments/{id}/ship/ Ship a shipment of transponders # List Couriers Source: https://docs.fleetit.com/api-reference/transponders/shipments/couriers get /v2/transponders/shipments/couriers/ Retrieve available shipment couriers. # Create Source: https://docs.fleetit.com/api-reference/transponders/shipments/create-return-shipment post /v2/transponders/shipments/ Create a shipment of transponders # Get Source: https://docs.fleetit.com/api-reference/transponders/shipments/get-one get /v2/transponders/shipments/{id}/ Get a shipment of transponders # List Source: https://docs.fleetit.com/api-reference/transponders/shipments/list get /v2/transponders/shipments/ List all shipments of transponders # Receive Source: https://docs.fleetit.com/api-reference/transponders/shipments/receive post /v2/transponders/shipments/{id}/receive/ Receive a shipment of transponders # Unassign Vehicle Source: https://docs.fleetit.com/api-reference/transponders/unassign-vehicle delete /v2/transponders/{id}/vehicle/ Unassign a vehicle from a transponder # Bulk Create Source: https://docs.fleetit.com/api-reference/vehicles/bulk-create post /v2/vehicles/bulk/ Create multiple vehicles in the system. Maximum 500 vehicles allowed per request. # Bulk Update Source: https://docs.fleetit.com/api-reference/vehicles/bulk-update patch /v2/vehicles/bulk/ Update multiple vehicles in the system. Maximum 500 vehicles allowed per request. Vehicles are identified by plate\_number and plate\_state combination. # Create Source: https://docs.fleetit.com/api-reference/vehicles/create post /v2/vehicles/ Create a new vehicle in the system. Custom fields are set at the fleet level by FleetIT. You can include custom field values when creating a vehicle, but you cannot create new custom field names. The system will only accept custom fields that are predefined for your fleet. # Export Source: https://docs.fleetit.com/api-reference/vehicles/export get /v2/vehicles/download/ Export vehicles from the system into a link of csv. # Get Source: https://docs.fleetit.com/api-reference/vehicles/get get /v2/vehicles/{id}/ Get a vehicle by ID. The response includes custom fields that are set at the fleet level by FleetIT. These fields contain vehicle-specific data configured for your fleet. # History Source: https://docs.fleetit.com/api-reference/vehicles/history get /v2/vehicles/{id}/history/ Retrieve a vehicle's status changes over time, newest first. A vehicle's `active` flag tells you where it stands today. This endpoint tells you where it stood at any past moment, which is what you need when deciding whether a toll happened while the vehicle was still on your fleet. Vehicles do get deactivated and brought back, so the current flag can't answer that on its own. Each entry is one revision: when it changed, whether the vehicle was on your fleet at that point, and who made the change. Entries cover every recorded change to a vehicle, not only the ones that moved it on or off the fleet, so consecutive entries can carry the same `active` value. ## Status at a point in time Ask for the newest revision at or before the moment you care about, then read its `active` value: ``` GET /v2/vehicles/{id}/history/?history_date__lte=2026-08-06T03:52:40Z&limit=1 ``` An empty result means nothing was recorded before that moment, so the vehicle's history starts later. History starts on 3 June 2023, when revision tracking was added. Vehicles deactivated before then have no entries, and a lookup for an earlier moment comes back empty rather than reporting a value. # List Source: https://docs.fleetit.com/api-reference/vehicles/list get /v2/vehicles/ Retrieve a list of all vehicles in the system. # Update Source: https://docs.fleetit.com/api-reference/vehicles/update patch /v2/vehicles/{id}/ Update a vehicle by ID. Plate number and plate state cannot be updated after vehicle creation. Custom fields are set at the fleet level by FleetIT. You can update the values of existing custom fields, but you cannot create new custom field names or modify the field structure. # List Vehicle Types Source: https://docs.fleetit.com/api-reference/vehicles/vehicle-types get /v2/vehicles/types/ Retrieve a list of all vehicle types in the system. # Billing Plans Source: https://docs.fleetit.com/documentation/billing-plans What a billing plan is, how charges are computed, and how plans turn usage into invoices. A **billing plan** is a reusable rule set that turns a driver's raw usage (currently toll tickets) into money on an [invoice](/documentation/driver-billing). A plan is defined once; the system uses it to generate invoices as agreements accumulate usage. ``` Billing Plan ──assigned to──▶ Agreement (or Fleet default) │ │ contains ▼ Charges ──computed against──▶ Driver's tickets ──produces──▶ Invoice fees ``` Three layers: 1. **Plan** — the container plus global settings (grace periods, due dates). 2. **Charges** — the line-item rules inside a plan. 3. **Invoices** — the output (see [Driver Billing Overview](/documentation/driver-billing)). ## The plan A plan belongs to a **fleet**. A fleet can have many plans. A plan applies to an agreement in one of two ways: * **Directly assigned** to an agreement, or * **Fleet default** — used by any agreement without its own plan. Which plan bills a driver = the agreement's own plan, else the fleet default. If neither exists, no invoice can be generated. ### Plan settings | Field | Type | Controls | | -------------------------------- | ---------------- | --------------------------------------------------------------------------------------------------------------------------------- | | `name` | text | Display label. | | `is_active` | boolean | Inactive plans are soft-deleted. | | `effective_date` | date (optional) | Agreements that **ended before** this date won't generate invoices. Blank = no cutoff; avoids back-billing historical agreements. | | `progressive_billing_threshold` | money (optional) | Amount of unbilled usage that triggers a mid-agreement invoice. Blank = only bill when the agreement ends. | | `grace_period_hours` | integer | Hours after an invoice is created before it can be finalized (default/manual trigger). | | `progressive_grace_period_hours` | integer | Same, for progressive invoices. | | `late_ticket_grace_period_hours` | integer | How long a late-ticket draft stays open to batch in more late tickets before finalizing. | | `payment_due_hours` | integer | Hours after finalization until payment is due (drives the due date / overdue flag). | | `payment_instructions` | rich text / HTML | Rendered in the "Payment Instructions" section of the invoice PDF. | All `*_hours` values are **durations in hours**, not timestamps. ## Charges A **charge** is one billable line. A plan has an ordered list of them. Each charge selects some tickets, reduces them to a quantity, multiplies by a unit rate, and produces one invoice line: ``` quantity × unit rate = line total 10 × $1.00 = $10.00 ``` ### Charge fields | Field | Meaning | | -------------------------- | ------------------------------------------------------------------------------------------------------- | | `description` | The label shown on the invoice line (e.g. "Toll pass-through"). | | `source_type` | What kind of record this charge bills. Currently only **`tolls`** is supported (citations are planned). | | `aggregation_type` | How to reduce matching records to a number: `count`, `sum`, or `count_unique`. | | `aggregation_field` | Which field to sum / count-unique on. Required for `sum` and `count_unique`; **not used** for `count`. | | `amount` | The per-unit rate (money), multiplied by the aggregated quantity. | | `filters` | Which records this charge applies to (see below). Empty = all of the driver's tickets. | | `order` | Position of the line on the invoice. | | `display_aggregated_value` | If `false`, hide the quantity column on the PDF for this line. | | `display_rate_value` | If `false`, hide the unit-rate column on the PDF for this line. | ### Aggregation types * **`count`** — number of matching tickets. Ignores `aggregation_field`. Example: "$2.00 per toll" → `count` × `$2.00\`. * **`sum`** — add up `aggregation_field` across matching tickets. Example: pass through the raw toll cost → `sum` of `amount` × `$1.00`. * **`count_unique`** — number of **distinct** values of `aggregation_field`. Example: charge per unique day driven → `count_unique` of `transaction_date`. ### Aggregation fields The field that `sum` / `count_unique` operates on: * **`amount`** — the toll's face amount. * **`cash_cost`** — the fleet's negotiated cost (respects an amount-override setting); falls back to `amount` when no cash cost exists. * **`transaction_date`** — mostly useful with `count_unique` (unique days). When `aggregation_type` is `sum` or `count_unique`, `aggregation_field` is required. For `count` it is not used. ### Filters Filters narrow which tickets a charge applies to. A charge's `filters` is a list; **all** filters must match (logical AND). Each filter is a triple: ```json theme={null} { "field": "agency", "op": "eq", "value": "MTA" } ``` Supported **fields**: `agency`, `transaction_date`, `exit_plaza`, `amount`. Supported **operators** (`op`): | op | Meaning | `value` shape | | ----- | ---------- | ------------- | | `eq` | equals | scalar | | `neq` | not equals | scalar | | `in` | one of | **list** | | `gte` | ≥ | scalar | | `lte` | ≤ | scalar | When `op` is `in`, `value` must be a list. Fields and operators outside the supported sets are rejected by the backend. ### Examples "Charge \$1.25 for every MTA toll": ``` description: "MTA tolls" source_type: tolls aggregation_type: count aggregation_field: (none) amount: 1.25 filters: [{ field: agency, op: eq, value: "MTA" }] ``` "Pass through the cash cost of all tolls over \$5": ``` aggregation_type: sum aggregation_field: cash_cost amount: 1.00 filters: [{ field: amount, op: gte, value: "5.00" }] ``` ## From plan to invoice Each invoice records **why** it was generated. The trigger maps to a plan setting: | Trigger | When it fires | Related plan setting | | ----------------- | -------------------------------------------------------------------- | ----------------------------------------------------------------- | | `PROGRESSIVE` | Unbilled usage crosses `progressive_billing_threshold` mid-agreement | `progressive_billing_threshold`, `progressive_grace_period_hours` | | `AGREEMENT_ENDED` | The agreement ends | `grace_period_hours`, `effective_date` | | `LATE_TICKET` | Tickets arrive after the agreement already ended/was billed | `late_ticket_grace_period_hours` | | `MANUAL` | A user generates one on demand | `grace_period_hours` | The three grace-period settings exist because each maps to one automated trigger. See the [invoice lifecycle](/documentation/driver-billing#invoice-lifecycle) for how a draft becomes finalized. ### Plan snapshot When an invoice is created, the plan and its charges are **frozen into the invoice** as a snapshot. Editing the plan afterward does **not** change existing invoices — only future ones. Plan details shown on an invoice come from its snapshot, not the live plan. To correct an already-created invoice, use a fee adjustment (draft) or a credit note (finalized). ## Corrections Two distinct concepts: * **Fee adjustment** — edits a line on a **DRAFT** invoice before it is finalized. Overrides the quantity and/or unit rate for one charge line, with a reason. Original values are preserved. * **Credit note** — issued against a **FINALIZED** invoice to refund/reduce it after the fact. Has its own number, reason, line items, and PDF. The credit total can't exceed the invoice's remaining balance. Rule of thumb: **draft → adjust the fee; finalized → issue a credit note.** # Driver Billing Overview Source: https://docs.fleetit.com/documentation/driver-billing How billing plans, driver invoices, and credit notes fit together. Driver billing turns a driver's tolls (and other chargeable events) into invoices, then lets you finalize, collect, adjust, and credit them. Three resources are involved: * **Billing Plans** — the rate rules (`charges`) applied to an agreement's tickets. * **Driver Invoices** — a billed statement for an agreement over a period. * **Credit Notes** — a credit issued against a finalized invoice. ## Routing & scope All endpoints live under `/v2/` and are scoped to the authenticated user's fleet. Routes derive the fleet from the authenticated user; you cannot request another fleet's data. ## Conventions * **Money / quantities** are decimal *strings* (`"12.50"`), not floats. * **Timestamps** are ISO-8601 (`2026-05-16T14:03:00Z`); dates are `YYYY-MM-DD`. * **IDs** are integers. * **Pagination** is limit/offset (`limit`, `offset`); list responses are wrapped in `{ "count", "next", "previous", "results" }`. * **Errors** use the DRF format: field errors `{"field": ["message"]}`, general errors `{"detail": "message"}`. ## Invoice lifecycle Every invoice starts as a `DRAFT` and moves to one of two terminal statuses: | Status | Meaning | | ----------- | ------------------------------------------------------------------------------------------- | | `DRAFT` | Working state. `draft_total` holds the running total; `total` is `null`. Fees are editable. | | `FINALIZED` | Locked and immutable. `total` is set; PDF generation is triggered. Terminal. | | `VOID` | Cancelled. Terminal. | `FINALIZED` and `VOID` are terminal. (Voiding a `FINALIZED` invoice is planned but not yet implemented — today only `DRAFT` invoices are voided.) ### How invoices are created The `trigger` records why an invoice was created. Every type starts as a `DRAFT`. | Trigger | Created when | | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `MANUAL` | You call `generate` for an agreement. It captures the agreement's not-yet-invoiced tolls at that moment; it does **not** pick up tolls that arrive afterward. | | `PROGRESSIVE` | Automatically, off the plan's `progressive_billing_threshold`. Each incoming toll compares the agreement's running total against the threshold; crossing it generates a progressive invoice. | | `AGREEMENT_ENDED` | Automatically, when an agreement ends. | | `LATE_TICKET` | After an `AGREEMENT_ENDED` invoice is finalized, tolls that arrive later accumulate onto a late-ticket invoice. | ### DRAFT stage While `DRAFT`: * **Fees are editable** via [adjust fee](/api-reference/driver-invoices/adjust-fee). Tickets are not directly editable. * **Refresh** ([refresh](/api-reference/driver-invoices/refresh)) recalculates fees and pulls in any unbilled tickets. It is called before finalizing. * For `AGREEMENT_ENDED` invoices only, tickets that arrive while the invoice is in `DRAFT` are swallowed into it automatically. ### Finalization * **Automatic** finalization waits for the plan's grace period to end. * You can **finalize manually at any time** as an override, before the grace period ends. Finalizing locks the invoice (immutable), sets `total`, and triggers PDF generation. ### Payment status `payment_status` (`PENDING`, `SUCCEEDED`, `FAILED`) is set manually via the [payment status](/api-reference/driver-invoices/payment-status) endpoint — there is no payment integration. `is_overdue` is a marker only; being overdue has no automatic consequence. ### Plan snapshot On creation, the invoice freezes a copy of the plan and its charges in `plan_snapshot`. Fees are computed from this snapshot, not the live plan, so later plan edits don't change an existing invoice. Fee adjustments reference a charge by its 0-based `charge_snapshot_index` into `plan_snapshot.charges`. ## Credit notes A credit note credits a **finalized** invoice. The total must be greater than 0 and no more than the invoice balance (`total − credited_amount`). Create one via the invoice sub-route (`POST /driver-invoices/{id}/credit-notes/`); the resource itself supports read, `void`, and `download`. ## Documents (PDF) Invoice and credit-note PDFs are generated **asynchronously**. Poll the `download` action: | `pdf_status` | HTTP | Body | Action | | ------------------------- | ----- | --------------------------------------- | -------------------------------- | | `null` (never requested) | `202` | `{"detail": "PDF is being generated."}` | Enqueues generation. Poll again. | | `PENDING` / `IN_PROGRESS` | `202` | `{"detail": "PDF is being generated."}` | Poll again. | | `COMPLETE` | `200` | `{"url": "https://…"}` | Fetch the file at `url`. | The `download` action is the safe entry point because it triggers generation on the first call. Once `pdf_status` is `COMPLETE`, the `pdf_file` field on the object holds the same (time-limited) URL. ## CSV export `GET /driver-invoices/export/?channel=email` emails a CSV export (invoices, fees, tickets) in the background. `channel` must be `email`. All current list filters are honored, so the export mirrors the list query. It returns `200` immediately; the files are emailed, not returned in the response. # Error Codes Source: https://docs.fleetit.com/documentation/error-codes Error codes and messages returned by the API. ```text Errors theme={null} 200: Success 201: Created 304: Not Modified 400: Bad Request 401: Unauthorized 403: Forbidden 404: Not Found 500: Internal Server Error ``` # Fleetio Source: https://docs.fleetit.com/documentation/integrations/fleetio # Fleetio Integration Documentation ## Overview This document provides an overview of the Fleetio integration, detailing the endpoints used, fields sent for expense entries, the daily vehicle fetch process, and the logging system for active integrations and tolls. ## Endpoints Used ### Vehicle Endpoints * **Fetch All Vehicles**: `GET https://secure.fleetio.com/api/v1/vehicles` * **Fetch Archived Vehicles**: `GET https://secure.fleetio.com/api/v1/vehicles/archived` ### Webhook Endpoints * **Create Webhook**: `POST https://secure.fleetio.com/api/v1/webhooks` * **Get Webhooks**: `GET https://secure.fleetio.com/api/v1/webhooks` * **Delete Webhook**: `DELETE https://secure.fleetio.com/api/v1/webhooks/{id}` ### Expense Entry Endpoints * **Expense Entry**: `POST https://secure.fleetio.com/api/v1/expense_entries` ## Expense Entry Fields When creating expense entries, the following fields are sent. This includes custom fields that must be present on the Fleetio side: ### Common Fields * **expense\_entry\_type\_id**: The ID of the expense entry type. * **vehicle\_id**: The ID of the vehicle in Fleetio. * **occurred\_at**: The date and time when the expense occurred. * **total\_amount\_cents**: The total amount of the expense in cents. * **total\_amount**: The total amount of the expense. ### Custom Fields * **plate\_number**: The plate number of the vehicle. * **plate\_state**: The state of the vehicle's license plate. * **ticket\_id**: The ID of the ticket. * **pin**: The PIN associated with the vehicle. * **fleet\_liable**: Indicates whether the fleet is liable. * **transaction\_date\_time**: The date and time of the transaction. * **violation**: The violation number (for parking). * **notice\_number**: The notice number (for parking). * **issuing\_authority**: The issuing authority of the ticket. * **vehicle\_number**: The vehicle number. * **pdf**: URL to the PDF of the ticket (if available). * **fleetit\_fee**: The fee charged by Fleetio (for tolls). * **posting\_date**: The posting date of the transaction (for tolls). * **exit\_plaza**: The exit plaza (for tolls). * **cash\_cost**: The cash cost associated with the toll (for tolls). * **agency**: The agency managing the toll (for tolls). ## Daily Vehicle Fetch Process Vehicles are fetched from Fleetio once a day. The process involves fetching both active and archived vehicles using the specified endpoints. The integration checks for updates and new vehicles, processing and updating the local database accordingly. ### Fetching Vehicles 1. **Fetch Active Vehicles**: The system fetches all active vehicles using the `https://secure.fleetio.com/api/v1/vehicles` endpoint. 2. **Fetch Archived Vehicles**: The system fetches all archived vehicles using the `https://secure.fleetio.com/api/v1/vehicles/archived` endpoint. ## Logging System ### Active Integration Logs Logs for active integrations are created to track the daily vehicle fetch process. These logs include details about the number of vehicles fetched, added, updated, and any errors encountered. ### Toll Logs After sending a toll, logs are created for each toll transaction. These logs include: * **Timestamp**: When the log was created. * **Action**: Description of the action taken (e.g., "Send toll to Fleetio"). * **Direction**: Indicates whether the action was "sending" or "receiving". * **Success**: Indicates whether the action was successful. * **Response**: Details of the response from Fleetio. * **Payload**: The data sent in the request. * **Entity ID**: The ID of the toll entity. * **Entity Type**: The type of entity (e.g., "TICKET", "PARKING"). ### Example Log Entry ```json theme={null} { "timestamp": "2024-05-05T21:09:01.685651-04:00", "action": "Send toll to Fleetio", "direction": "sending", "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 }, "payload": { "expense_entry_type_id": 706773, "vehicle_id": "12345", "occurred_at": "2024-05-05T21:09:01.685651-04:00", "total_amount_cents": 1000, "total_amount": "10.00", "custom_fields": { "plate_number": "ABC123", "plate_state": "NY", "ticket_id": 1, "fleetit_fee": "5.00", "posting_date": "2024-05-05", "transaction_date_time": "2024-05-05 21:09:01", "exit_plaza": "Plaza 1", "cash_cost": "10.00", "agency": "Agency 1", "vehicle_number": "VN12345" } }, "entity_id": 1, "entity_type": "TICKET" } ``` # Hubspot Source: https://docs.fleetit.com/documentation/integrations/hubspot ## Setting Up HubSpot Integration for Toll Data Management In this post, we will guide you through the process of setting up a HubSpot integration for managing toll data. The integration involves creating and associating custom objects in HubSpot to streamline toll record management and vehicle contracts. ### Introduction HubSpot provides powerful tools for managing customer relationships and business processes. By integrating toll data management with HubSpot, you can automate toll record creation, associate tolls with vehicle contracts, and maintain a comprehensive record of toll-related activities. This blog post will cover the configuration requirements, steps to obtain necessary IDs, and how to fill out the integration form. ### Configuration Form Fields To set up the HubSpot integration, you'll need to fill out a configuration form with specific details. Let's walk through each field in the form and explain what is required. #### 1. Access Token * **Type**: Text Input * **Description**: The access token required to authenticate requests to the HubSpot API. #### 2. Toll Custom Object Type Id * **Type**: Text Input * **Description**: The custom object type ID for tolls in HubSpot. This ID is required to identify the toll custom object. #### 3. Toll Vehicle Association Id * **Type**: Text Input * **Description**: The association type ID between tolls and vehicles in HubSpot. This ID is required to link toll records with vehicle contracts. #### 4. Vehicle Custom Object Type Id * **Type**: Text Input * **Description**: The custom object type ID for vehicles in HubSpot. This ID is required to identify the vehicle custom object. #### 5. Match Toll Based On Vehicle Agreements Date * **Type**: Checkbox * **Description**: If checked, tolls will be matched based on the vehicle agreements date. This ensures that tolls are correctly associated with the appropriate vehicle contracts based on their active agreement periods. #### 6. Vehicle Agreement End Date Property Internal Name * **Type**: Text Input * **Description**: The internal name of the property for the vehicle agreement end date. This field is required if matching tolls based on vehicle agreements date. #### 7. Vehicle Agreement Start Date Property Internal Name * **Type**: Text Input * **Description**: The internal name of the property for the vehicle agreement start date. This field is required if matching tolls based on vehicle agreements date. #### 8. Vehicle Custom Object Property Internal Name For Plate State * **Type**: Text Input * **Description**: The internal name of the property for the vehicle's plate state. This field is required to identify the vehicle's plate state. #### 9. Vehicle Custom Object Property Internal Name For Plate Number * **Type**: Text Input * **Description**: The internal name of the property for the vehicle's plate number. This field is required to identify the vehicle's plate number. ### Example Configuration Form Filling Here is an example of how the form might be filled out: * **Access Token**: \[Your HubSpot Access Token] * **Toll Custom Object Type Id**: 2-31601055 * **Toll Vehicle Association Id**: 140 * **Vehicle Custom Object Type Id**: 2-31442987 * **Match Toll Based On Vehicle Agreements Date**: \[Checked] * **Vehicle Agreement End Date Property Internal Name**: rental\_end\_date * **Vehicle Agreement Start Date Property Internal Name**: rental\_start\_date * **Vehicle Custom Object Property Internal Name For Plate State**: plate\_state * **Vehicle Custom Object Property Internal Name For Plate Number**: license\_plate ### Obtaining Required IDs and Property Internal Names #### 1. Access Token To interact with HubSpot's API, you'll need an access token. Here’s how you can generate one: 1. Navigate to your HubSpot account. 2. Go to **Settings** > **Integrations** > **API Key** or **Private Apps**. 3. Create a new API key or private app to generate an access token. 4. Copy and paste the access token into the **Access Token** field in the configuration form. #### 2. Custom Object Type IDs You need to create custom objects for tolls and vehicles in HubSpot and note down their IDs: 1. Navigate to **Settings** > **Objects** > **Custom Objects** in HubSpot. 2. Create custom objects for tolls and vehicles. 3. Note down the IDs assigned to these custom objects, and enter them in the **Toll Custom Object Type Id** and **Vehicle Custom Object Type Id** fields. #### 3. Association IDs Set up associations between the toll and vehicle custom objects to manage relationships: 1. Navigate to **Settings** > **Objects** > **Associations**. 2. Set up the association between the toll and vehicle custom objects. 3. Note down the ID assigned to this association and enter it in the **Toll Vehicle Association Id** field. #### 4. Property Internal Names For each custom object, navigate to **Settings** > **Objects** > **Custom Objects** and note down the internal names of the required properties: 1. Select the custom object (toll or vehicle). 2. Navigate to **Properties**. 3. Note down the internal names for: * Plate number: Enter in **Vehicle Custom Object Property Internal Name For Plate Number**. * Plate state: Enter in **Vehicle Custom Object Property Internal Name For Plate State**. * Agreement start date (if applicable): Enter in **Vehicle Agreement Start Date Property Internal Name**. * Agreement end date (if applicable): Enter in **Vehicle Agreement End Date Property Internal Name**. ### Required Custom Object Properties #### Toll Custom Object The toll custom object must have the following properties and types: * **id**: *String* - Unique identifier for the toll. * **amount**: *Number* - Amount of the toll. * **fee**: *Number* - Fee associated with the toll. * **exit\_plaza**: *String* - Exit plaza where the toll was collected. * **exit\_plaza\_cash\_cost**: *Number* - Cash cost at the exit plaza. * **posting\_date**: *Date* - Date the toll was posted. * **transaction\_date\_time**: *Datetime* - Date and time of the toll transaction. #### Ve hicle Custom Object The vehicle custom object must have the following properties and types: * **vehicle\_custom\_object\_property\_internal\_name\_for\_plate\_number**: *String* - Internal name for the plate number property. * **vehicle\_custom\_object\_property\_internal\_name\_for\_plate\_state**: *String* - Internal name for the plate state property. If **Match Toll Based On Vehicle Agreements Date** is checked, the following properties are also required: * **vehicle\_agreement\_start\_date\_property\_internal\_name**: *Date* - Internal name for the agreement start date property. * **vehicle\_agreement\_end\_date\_property\_internal\_name**: *Date* - Internal name for the agreement end date property. ### Required Scopes To use this integration, you must have the following scopes in your HubSpot access token: * `crm.objects.custom.read` - Required to read custom objects. * `crm.objects.custom.write` - Required to write custom objects. * `crm.schemas.custom.read` - Required to read custom object schemas. * `crm.objects.contacts.read` - Required to read contacts. * `crm.schemas.contacts.read` - Required to read schema contacts. These scopes are required to access and manage custom objects and schemas in HubSpot. Setting up HubSpot integration for toll data management can significantly streamline your business processes. By following the steps outlined in this post, you can ensure that your toll data is accurately managed and associated with vehicle contracts in HubSpot. For more detailed instructions, refer to the official HubSpot [documentation](https://www.hubspot.com/products/custom-objects). If you encounter any issues or need further assistance, please contact HubSpot support. *** # Submit Test Toll Source: https://docs.fleetit.com/documentation/integrations/test-tolls > **Note:** This endpoint is only available in the **staging** environment and requires special permissions granted by administrators. ## Endpoint `POST https://api.staging.fleetit.com/api/tickets/individual/` ## Description This endpoint enables the submission of a dummy toll ticket for a specified vehicle and transaction with authentication. It either creates a new toll ticket or returns error messages if there are issues with the request or specific business rules are triggered. Tolls are not sent immediately; instead, they are queued and processed for integration in the background. *** ## Request Body Parameters | Parameter | Type | Description | | ------------------ | -------- | ------------------------------------------------------------------------------------------------------- | | `transaction_date` | `string` | Date of the toll transaction in `YYYY-MM-DD` format. | | `exit_time` | `string` | Time of exit in `HH:MM:SS` format. | | `exit_plaza` | `string` | Identifier for the exit plaza e.g `"HT"`. | | `agency` | `string` | Agency code associated with the toll (e.g., `"PANYNJ"`). | | `amount` | `float` | Toll amount charged. | | `plate_number` | `string` | License plate number of the vehicle of your fleet. Vehicle must be added prior to submitting test toll. | | `plate_state` | `string` | State code of the vehicle registration (e.g., `"NY"`). | ### Sample Request Payload ```json theme={null} { "transaction_date": "2024-08-15", "exit_time": "01:55:00", "exit_plaza": "HT", "agency": "PANYNJ", "amount": 100.0, "plate_number": "ABC123", "plate_state": "NY" } ``` ## Responses ### 201 Created **Description:** The toll ticket was successfully created. **Sample Response:** ```json theme={null} { "exit_plaza": "HT", "agency": "PANYNJ", "amount": 100.0, "plate_number": "ABC123", "plate_state": "NY", "vehicle": 7848 } ``` ### 400 Created #### Case 1 **Description:** The submitted ticket is a duplicate of an existing one. **Sample Response:** ```json theme={null} { "queue_reason": [ "Duplicate of existing ticket: 11746" ] } ``` #### Case 2 **Description:** The ticket submission matches specific business rules and cannot proceed. **Sample Response:** ```json theme={null} { "queue_reason": [ "Ticket matches business rule(s): All February Tolls" ] } ``` ### 403 Created **Description:** You do not have permission to perform this action. Contact Support. **Sample Response:** ```json theme={null} { "detail": "You do not have permission to perform this action." } ``` ## Error Codes | Status Code | Description | | ----------- | --------------------------------------------------------------- | | **201** | Toll ticket created successfully. | | **400** | Bad request due to duplicate ticket or business rule violation. | | **403** | Forbidden: User lacks necessary permissions. | ## Additional Information * **Environment:** This endpoint is exclusive to the staging environment. * **Permissions:** Access requires special permissions that can be obtained from an administrator. ## Usage Notes * Ensure that all date and time fields are formatted correctly. * The `amount` should be a positive number representing the toll charge. * Make sure you have the necessary permissions before attempting to use this endpoint. # Webhook Source: https://docs.fleetit.com/documentation/integrations/webhook ## Tolls Webhook URL When setting up webhooks in our system for toll notifications, you will be asked to specify a URL where you would like to receive the webhook notifications. #### Example Payload ```json theme={null} { "type": "ticket", "ticketID": 1, "amount": "10", "fee": "0", "exit_plaza": "X EXIT PLAZA", "exit_plaza_cash_cost": "10", "posting_date": "1970-01-01 00:00:00.000000+00:00", "trans_date_time": "1970-01-01 00:00:00", "vehicle_plate_number": "123456", "vehicle_tracking_number": "", "vehicle_plate_state": "NY", "custom_fields" : { "field1": "value1", "field2": "value2" } } ``` Custom Fields are only sent if you have configured them in the webhook settings. ## Parking Webhook URL When setting up webhooks in our system for parking notifications, you will be asked to specify a URL where you would like to receive the webhook notifications. #### Example Payload ```json theme={null} { "type": "ticket", "issuing_authority": "X Issuing Authority", "violation_number": "1234567890", "ticket_type": "Parking", "description": "Lorem ipsum dolor sit amet", "date": "1970-01-01", "time": "00:00:00", "vehicle": "123456", "vehicle_state": "NY", "fine_amount": "10", "transfer_of_liability": "False", "fleet_liable": "False", "pdf": "", "custom_fields" : { "field1": "value1", "field2": "value2" } } ``` ## Response Handling Your endpoint should handle the incoming POST requests and respond with a 200 OK status code to acknowledge the successful receipt of the webhook. #### Example Response ```json theme={null} { "status": "success", "message": "Webhook received successfully" } ``` ## Security and Best Practices * Ensure your endpoint is secured using HTTPS. * Ensure you have duplicate logic handling for tickets identificaitons. * Set up error handling to manage different types of webhook events and potential issues with payload processing. ## Headers Information When receiving webhook notifications, the following headers will be sent along with the payload: ### Custom Configured Headers Any headers specified in the webhook configuration settings. ### Fleet-Specific Headers * **Ext-Client-Id**: Provided if available from `customer_info`. * **Ext-Billing-Id**: Provided if available from `customer_info`. ### Generic Headers * **Fleet-Id**: The fleet ID associated with the webhook. * **X-Timestamp**: A UNIX timestamp of when the webhook was sent. * **X-Signature**: An HMAC SHA-256 signature generated using a secret key, the payload, and the timestamp for security verification. ## Signature in Webhooks To ensure the security and authenticity of the webhook notifications, a signature is generated and included in the headers of each webhook request. This signature allows the receiving endpoint to verify the integrity of the payload. ### How the Signature is Generated The signature is created using an HMAC SHA-256 hashing process that involves the following components: * **Secret Key**: The `webhook_signature_secret_token` from your active webhook integration. * **Data**: The payload of the webhook. * **Timestamp**: The UNIX timestamp representing when the webhook was sent. The signature is generated using the following Python code: ```python theme={null} import json import hmac import hashlib def generate_signature(secret_key, data, timestamp): serialized_payload = json.dumps(data, separators=(',', ':')) signed_payload = f"{timestamp}.{serialized_payload}" signature = hmac.new(secret_key.encode(), signed_payload.encode(), hashlib.sha256).hexdigest() return signature ``` ### Obtaining the Secret Key The secret key required for signature verification can be obtained from the [Fleet Active Integrations API](/api-reference/integrations/fleet-active-integrations/list). After creating a webhook integration, the integration details will include the `webhook_signature_secret_token` field. #### Example Response from Fleet Active Integrations: ```json theme={null} { "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" } ] } ``` The `webhook_signature_secret_token` field contains the secret key that should be used for signature verification. # Multi-Fleets Management Source: https://docs.fleetit.com/documentation/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: ```text Plain Text theme={null} 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. # Overview Source: https://docs.fleetit.com/documentation/overview ## 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. # Pagination Source: https://docs.fleetit.com/documentation/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 ```text Plain Text theme={null} 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. # Rate limiting Source: https://docs.fleetit.com/documentation/rate-limiting Our API implements rate limiting to ensure fair use and maintain optimal performance for all users. Rate limiting is applied to both authenticated and anonymous users, with limits set to balance accessibility and security. ## Understanding Rate Limiting Rate limiting controls the number of requests a user can make to the API within a certain period. When a user exceeds their allotted number of requests, the API will temporarily block further requests from that user. ### What Happens When the Limit is Exceeded? If you exceed the allowed rate limit, you will receive a `429 Too Many Requests` response from the API. This response indicates that you have made too many requests in a short period. The API response will include the following important header: * **`Retry-After` Header**: This header indicates the number of seconds you should wait before making another request. It helps you understand when your request quota will be reset and when you can resume making requests. ## Best Practices for API Usage To ensure smooth interaction with our API and to avoid hitting rate limits, we recommend the following best practices: 1. **Monitor Your Request Patterns**: Keep track of how frequently your application is making requests to the API. By understanding your usage patterns, you can adjust your application’s behavior to avoid exceeding rate limits. 2. **Implement Retry Logic**: Incorporate retry logic into your application. If you receive a `429 Too Many Requests` response, your application should wait for the period specified in the `Retry-After` header before retrying the request. 3. **Optimize Your API Calls**: Where possible, reduce the number of API calls by batching requests or minimizing redundant requests. This helps in staying within the rate limits while still achieving your goals. 4. **Use Authenticated Requests When Possible**: If your API usage requires higher request limits, ensure that you authenticate your requests, as authenticated users may have more favorable rate limits. 5. **Graceful Degradation**: Design your application to handle rate limits gracefully. If rate limiting affects the performance or functionality of your application, implement fallback mechanisms to maintain a good user experience. *** # Obtain Token Source: https://docs.fleetit.com/api-reference/auth/obtain-token post /api/auth/token/ Exchange credentials for an access token. # Refresh Token Source: https://docs.fleetit.com/api-reference/auth/refresh-token post /api/auth/token/refresh/ Exchange a refresh token for a new access token. The request requires a valid refresh token to be present in the cookie named `refresh_token` # Create Billing Plan Source: https://docs.fleetit.com/api-reference/billing-plans/create post /v2/billing-plans/ Create a billing plan with its charges. # Delete Billing Plan Source: https://docs.fleetit.com/api-reference/billing-plans/delete delete /v2/billing-plans/{id}/ Soft-delete a billing plan. Soft-delete: sets `is_active` to `false` rather than removing the record. # Get Billing Plan Source: https://docs.fleetit.com/api-reference/billing-plans/get get /v2/billing-plans/{id}/ Retrieve a single billing plan. # List Billing Plans Source: https://docs.fleetit.com/api-reference/billing-plans/list get /v2/billing-plans/ Retrieve all billing plans. # Update Billing Plan Source: https://docs.fleetit.com/api-reference/billing-plans/update patch /v2/billing-plans/{id}/ Update a billing plan; the charges array is a full replacement. On `PATCH`, the `charges` array is a **full replacement**: charges omitted (by `id`) are deleted, charges with a known `id` are updated, and charges without an `id` are created. # Create Payment Method Source: https://docs.fleetit.com/api-reference/billing/payment-methods/create post /v2/billing/payment-methods/ Add a new payment method to the fleet. # Get Default Payment Method Source: https://docs.fleetit.com/api-reference/billing/payment-methods/get-default get /v2/billing/payment-methods/default/ Retrieve the fleet's default payment method. # List Payment Methods Source: https://docs.fleetit.com/api-reference/billing/payment-methods/list get /v2/billing/payment-methods/ Retrieve all payment methods for the fleet. # Remove Payment Method Source: https://docs.fleetit.com/api-reference/billing/payment-methods/remove post /v2/billing/payment-methods/remove/ Remove a payment method from the fleet. # Set Default Payment Method Source: https://docs.fleetit.com/api-reference/billing/payment-methods/set-default put /v2/billing/payment-methods/default/ Set a payment method as the fleet default. # Create Billing Status Source: https://docs.fleetit.com/api-reference/billing/statuses/create post /v2/billing_statuses/ Create a new billing status. # Delete Billing Status Source: https://docs.fleetit.com/api-reference/billing/statuses/delete delete /v2/billing_statuses/{id}/ Delete a billing status by ID. # Get Billing Status Source: https://docs.fleetit.com/api-reference/billing/statuses/get get /v2/billing_statuses/{id}/ Retrieve a billing status by ID. # List Billing Statuses Source: https://docs.fleetit.com/api-reference/billing/statuses/list get /v2/billing_statuses/ Retrieve all billing statuses. # Patch Billing Status Source: https://docs.fleetit.com/api-reference/billing/statuses/patch patch /v2/billing_statuses/{id}/ Partially update a billing status by ID. # Update Billing Status Source: https://docs.fleetit.com/api-reference/billing/statuses/update put /v2/billing_statuses/{id}/ Replace a billing status by ID. # Bulk Create Source: https://docs.fleetit.com/api-reference/drivers/create-bulk post /v2/drivers/bulk/ Creates multiple drivers in system # Update Driver Source: https://docs.fleetit.com/api-reference/drivers/update patch /v2/drivers/{id}/ Partially update a driver by ID. # Stats: Citations Count Source: https://docs.fleetit.com/api-reference/stats/citations-count get /v2/stats/citations/count/ Retrieve citation count statistics. # Stats: Citations Volume Source: https://docs.fleetit.com/api-reference/stats/citations-volume get /v2/stats/citations/volume/ Retrieve citation volume statistics. # Stats: Tolls Count Source: https://docs.fleetit.com/api-reference/stats/tolls-count get /v2/stats/tolls/count/ Retrieve toll count statistics. # Stats: Tolls Distribution Source: https://docs.fleetit.com/api-reference/stats/tolls-distribution get /v2/stats/tolls/distribution/ Retrieve toll distribution statistics. # Stats: Tolls Volume Source: https://docs.fleetit.com/api-reference/stats/tolls-volume get /v2/stats/tolls/volume/ Retrieve toll volume statistics. # Stats: Vehicles Count Source: https://docs.fleetit.com/api-reference/stats/vehicles-count get /v2/stats/vehicles/count/ Retrieve vehicle count statistics. # Stats: Vehicles Volume Source: https://docs.fleetit.com/api-reference/stats/vehicles-volume get /v2/stats/vehicles/volume/ Retrieve vehicle volume statistics. # Add Comment Source: https://docs.fleetit.com/api-reference/support-tickets/comments/create post /v2/support-tickets/{id}/comments/ Add a comment to a support ticket. # Delete Comment Source: https://docs.fleetit.com/api-reference/support-tickets/comments/delete delete /v2/support-tickets/{id}/comments/{comment_id}/ Delete a support ticket comment. # Update Comment Source: https://docs.fleetit.com/api-reference/support-tickets/comments/update patch /v2/support-tickets/{id}/comments/{comment_id}/ Update a support ticket comment. # Create Support Ticket Source: https://docs.fleetit.com/api-reference/support-tickets/create post /v2/support-tickets/ Create a new support ticket. # Delete Support Ticket Source: https://docs.fleetit.com/api-reference/support-tickets/delete delete /v2/support-tickets/{id}/ Delete a support ticket by ID. # Get Support Ticket Source: https://docs.fleetit.com/api-reference/support-tickets/get get /v2/support-tickets/{id}/ Retrieve a support ticket by ID. # List Support Tickets Source: https://docs.fleetit.com/api-reference/support-tickets/list get /v2/support-tickets/ Retrieve all support tickets. # Update Support Ticket Source: https://docs.fleetit.com/api-reference/support-tickets/update patch /v2/support-tickets/{id}/ Partially update a support ticket by ID. # Error Codes Source: https://docs.fleetit.com/documentation/error-codes Error codes and messages returned by the API. ```text Errors theme={null} 200: Success 201: Created 304: Not Modified 400: Bad Request 401: Unauthorized 403: Forbidden 404: Not Found 500: Internal Server Error ``` # Multi-Fleets Management Source: https://docs.fleetit.com/documentation/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: ```text Plain Text theme={null} 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. # Overview Source: https://docs.fleetit.com/documentation/overview ## 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. # Pagination Source: https://docs.fleetit.com/documentation/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 ```text Plain Text theme={null} 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. # Rate limiting Source: https://docs.fleetit.com/documentation/rate-limiting Our API implements rate limiting to ensure fair use and maintain optimal performance for all users. Rate limiting is applied to both authenticated and anonymous users, with limits set to balance accessibility and security. ## Understanding Rate Limiting Rate limiting controls the number of requests a user can make to the API within a certain period. When a user exceeds their allotted number of requests, the API will temporarily block further requests from that user. ### What Happens When the Limit is Exceeded? If you exceed the allowed rate limit, you will receive a `429 Too Many Requests` response from the API. This response indicates that you have made too many requests in a short period. The API response will include the following important header: * **`Retry-After` Header**: This header indicates the number of seconds you should wait before making another request. It helps you understand when your request quota will be reset and when you can resume making requests. ## Best Practices for API Usage To ensure smooth interaction with our API and to avoid hitting rate limits, we recommend the following best practices: 1. **Monitor Your Request Patterns**: Keep track of how frequently your application is making requests to the API. By understanding your usage patterns, you can adjust your application’s behavior to avoid exceeding rate limits. 2. **Implement Retry Logic**: Incorporate retry logic into your application. If you receive a `429 Too Many Requests` response, your application should wait for the period specified in the `Retry-After` header before retrying the request. 3. **Optimize Your API Calls**: Where possible, reduce the number of API calls by batching requests or minimizing redundant requests. This helps in staying within the rate limits while still achieving your goals. 4. **Use Authenticated Requests When Possible**: If your API usage requires higher request limits, ensure that you authenticate your requests, as authenticated users may have more favorable rate limits. 5. **Graceful Degradation**: Design your application to handle rate limits gracefully. If rate limiting affects the performance or functionality of your application, implement fallback mechanisms to maintain a good user experience. ***