Scope the connection
Confirm the provider, account owner, required data, allowed actions, refresh expectations, and the Haultro workflows that will use it.
Integration readiness
Connection status should answer what works and what is still required.
A provider logo is not proof of a working integration. Haultro separates the implemented software contract from the customer account, credential, hardware, consent, commercial plan, and acceptance evidence required to use it in production.
Accounting & payments
QuickBooksAdapter built; OAuth activation required
XeroAdapter built; OAuth activation required
StripeBuilt; account and webhook activation required
ACH / card processingBuilt through Stripe; account activation required
Stripe ConnectBuilt; Connect onboarding required
Telematics & ELD
SamsaraAdapter built; tenant credential acceptance required
GeotabAdapter built; tenant credential acceptance required
Verizon ConnectAdapter built; tenant credential acceptance required
MotiveAdapter built; tenant credential acceptance required
ELD providersImport contract built; provider acceptance required
Maps & routing
Mapping & geocodingAdapter built; provider key required
Live trafficAdapter built; provider plan required
Address validationAdapter built; provider key required
Hardware & scales
Smart-bin ingestBuilt; device and field acceptance required
High-volume IoT ingestionReference-tested above 2M readings/day
GPS and roll-off hardwareExternal hardware activation required
Scale-ticket importBuilt
Certified-scale connectionNamed provider and sandbox still required
Comms & notifications
SMS & emailAdapters built; sender/provider configuration required
Customer notificationsWorkflow built; delivery provider required
WebhooksBuilt with signing, retry, and delivery history
Developer
Customer API v1 (7 operations / 6 paths)Built with scoped keys, rotation, rate limits, audit, and idempotent service-order writes
Internal platform API (150+ endpoints)Used by Haultro workspaces and services; not an open customer API contract
WebhooksBuilt
API keys & scopesBuilt
"Built" means the repository implements the contract and failure handling. It does not mean a customer's third-party account is connected. Provider-backed items stay unavailable until credentials, consent, plan eligibility, and sandbox acceptance are complete.
Activation process
Connect a provider without blurring responsibility.
The exact checks vary by provider, but every production integration needs a named owner, an explicit data contract, test evidence, and a visible failure state.
Authorize access
Use the customer-owned account, credential, OAuth grant, API key, device, or webhook secret required by that provider.
Validate in a sandbox
Check field mapping, tenant boundaries, failure behavior, retries, and representative records before production acceptance.
Monitor the boundary
Keep connection health, rejected records, webhook delivery, credential rotation, and provider changes visible after activation.
Source attribution
Keep provider evidence identifiable.
Location, hours, fault, payment, scale, and fill records should retain their source and freshness so teams know what they are deciding from.
Least access
Authorize the workflow, not the whole account.
Scope credentials and API keys to the agreed operation, keep tenant boundaries intact, and rotate access under the customer-provider relationship.
Failure truth
Make stale and unavailable states visible.
Retries, rejected records, expired credentials, and provider downtime should be inspectable instead of silently presenting old or illustrative data as current.
Integration FAQ
Know the boundary before you connect it.
Does “adapter built” mean the integration is already live for my company?
No. It means the software contract and failure handling exist in the Haultro codebase. Your provider account, credentials, consent, plan eligibility, data mapping, sandbox tests, and production acceptance are separate activation gates.
Can Haultro connect to a provider that is not listed?
Possibly. The first step is to review the provider API, data rights, authentication method, rate limits, field coverage, and the exact workflow you need. A new connection requires a written scope and acceptance plan.
Who owns the third-party account and credentials?
The customer keeps control of the provider relationship and grants only the access needed for the agreed Haultro workflow. Credential ownership and rotation are confirmed during activation.
What happens when a provider is unavailable?
The integration should surface an unavailable or stale state and preserve the source boundary. Haultro does not substitute generated or demo data for a failed provider response.
Get started
Bring your stack with you.
Tell us what you run today and we'll map the integration.