Reference · built on requestConnectorFleet & telematics

Bringg

Delivery orders, waypoints, drivers, vehicles, routes, and carrier assignments from Bringg Own Fleet and Delivery Hub.

Request accessPricing ↗

About

Bringg is a delivery management platform with two products: Own Fleet for drivers you employ and Delivery Hub for third-party carriers. Its REST API takes orders from an OMS, vehicles from a VMS, and inventory from an ERP, and exposes drivers, teams, customers, service areas, delivery blocks, and runs. Webhooks report each step of the order life cycle, from task_created and driver_assigned to way_point_arrived, task_done, and task_late.

Through Fibric, an operator reads order status, driver location, and ETA changes, then proposes an order update, a driver assignment, or a release to dispatch for your approval. Approved changes go to Bringg once, with a receipt of what changed, why, and how to undo it.

This is a reference listing. It documents what Fibric would read from Bringg and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Orders (tasks) with waypoints, customer, inventory, and linked orders through Get Order, Get Open Orders, and Get Post Optimization Orders
  • Users, drivers, teams, vehicles, parking spots, and service areas through Get User, Get Users, Get Team Details, and Get All Vehicles
  • Driver availability and delivery blocks through Get Driver Availability and Get Drivers' Delivery Blocks
  • Order life cycle webhooks: task_created, driver_assigned, driver_on_the_way, way_point_arrived, way_point_left, task_done, task_cancelled, and task_late
  • ETA and schedule webhooks: way_point_eta_changed, way_point_schedule_changed, and way_point_scheduled_arrival_updated
  • Proof and attachments through note_created, which carries text, photo, signature, and form notes, plus created_form and rating_submitted
  • Carrier events in Delivery Hub through task_assigned_to_dp and accepted_by_fleet, and route events through run_started, run_ended, and route_optimization_done

Proposed actions

  • Target capability: propose a new order with waypoints, customer, and inventory through Create Order (Task) at /services/create_task
  • Target capability: propose an order update, an external ID change, or a cancellation through Update Order and Cancel Order (Task)
  • Target capability: propose assigning a driver to a route or releasing planned orders to dispatch through Assign Driver to Route and Release Orders
  • Target capability: propose a driver check-in or checkout at a waypoint through Check-in and Checkout
  • Target capability: propose a vehicle or team change through Update Vehicle and Update Team

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Tell the customer the new arrival time

    way_point_eta_changed arrives with the order and waypoint. The operator compares it with the delivery slot and proposes the customer message and, if needed, a rescheduled waypoint.

    With ETA Notice

  • File the proof of delivery

    note_created carries photo, signature, and form notes for a waypoint, and task_done closes the order. The operator assembles them into one proof record and proposes it for the order file.

    With Delivery Proof

  • Rescue an order marked late

    task_late fires when an order misses its scheduled time. The operator checks driver availability and proposes reassignment through Assign Driver to Route or a new delivery slot.

    With Missed Delivery

  • Release the day's routes

    After runs_planning_done and route_optimization_done, the operator reviews unassigned orders and proposes Release Orders and driver assignments for a dispatcher to approve.

    With Field Dispatch

Requirements

  • The Admin user type in Bringg to create OAuth 2.0 apps and register webhooks
  • An OAuth 2.0 app with only the read and write scopes the operator needs; an app cannot be edited once created
  • Your region's domain for OAuth calls, such as https://us2-admin-api.bringg.com or https://eu2-admin-api.bringg.com
  • Webhook URLs registered under Settings, Platform Integrations, Webhooks, with an authentication method and any static headers
Authentication
OAuth 2.0 client credentials: an app created under Settings, Platform Integrations, OAuth2 API gives a client_id and client_secret exchanged at /oauth/token on your region's admin-api domain for a JWT; Bringg Services are an alternative with unauthenticated URLs made of three GUIDs.

Limits

  • Access tokens default to a 30-minute TTL for write APIs and 4 hours for read APIs
  • Bringg sends each webhook three times; after a third failed attempt it lands in the Undelivered Webhooks Report
  • Inventory items per order are capped per account; Create Order returns an error when the limit is passed
  • Webhook order is not guaranteed because delivery is asynchronous

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Bringg ↗

Questions and answers

How do I authenticate API calls?
Create an OAuth 2.0 app under Settings, Platform Integrations, OAuth2 API and copy its client_id and client_secret; the secret is shown once. POST them to /oauth/token on your region's admin-api domain to get a JWT. Scopes map to endpoint groups, with default TTLs of 30 minutes for write and 4 hours for read.
Which webhooks cover a delivery?
task_created, driver_assigned, tasks_sent_to_driver, driver_on_the_way, way_point_arrived, way_point_left, task_done, task_cancelled, task_late, and way_point_eta_changed, among others in the Webhooks Index. Each is registered once under Settings, Platform Integrations, Webhooks, can be filtered by a field value, and can be trimmed with Enable Flexible Webhook.
What happens when a webhook is not received?
Bringg tries to send each webhook three times. After a third failed attempt without a confirmation from your system, the webhook is listed in the Undelivered Webhooks Report, which you can pull for a time period through Generate Undelivered Webhooks Report.
Ask about Bringg

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Bringg through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy