TireBuddy Toolkit Integration guide SDK and API implementation guide

TireBuddy Toolkit Integration guide

Define the features in your app and review the matching integration steps and configuration samples for your market.

The flow is organized in implementation order, from setup and app configuration through vehicle and tire scanning, tread measurement, output handling, and final validation.

Prerequisites: This guide assumes active Anyline SDK license keys and an Anyline client ID for the Insights API. See License Key Generation documentation.

Define Scope

Choose the features in your app

How to use this step

Turn on only the features your app will include in the first release. The guide hides unrelated steps and shows the matching integration path and checklist below. Some options are alternatives, not add-ons. Choose the flow that matches your app.

Select your platform

Platform-specific references update below. Android and iOS native documentation stays visible for both platforms.

Select your main market

License plate, VIN validation, and DOT or TIN defaults vary by region. The labels below update the guide immediately.

Vehicle identification

Choose the vehicle-identification flow for your app.

Use OCR when your app needs only VIN OCR. Switch to OCR + barcode when your app needs the VIN scanned via barcode and OCR.

Tire diagnostics

Choose the tire diagnostics flow for your app.

Use Production date as the default for most integrations. Switch to Full DOT only when a workflow needs the complete DOT / TIN string.

Integration map This diagram updates from the selected features, region, and options. It shows which components your app owns and which Anyline provides, not the order of calls; the step-by-step flows are in Steps 5 to 7.
2
Foundation

Initialize the SDKs

Initialize both SDKs in one setup step

  • Initialize the Tire Tread SDK and the Mobile SDK together, as one setup step, once, early in the app lifecycle, and before any scan screen can open. The order between the two does not matter; neither SDK depends on the other being initialized. We strongly recommend running both from the same place in your code so they cannot drift apart.
  • Each SDK takes its own license key. The Tire Tread SDK license key initializes the SDK for tread scanning; the Mobile SDK key covers the OCR and barcode scanners. Sidewall is part of the Tire Tread SDK but runs as a separate scanner that does not use the license key or initialize(); it authenticates only with the client ID described below. Keep the keys out of the scan screens and pass them at initialization only.
  • Treat the step as complete only when both initializations have succeeded. If either fails, keep every scan entry point disabled and show a startup error with a retry, instead of letting the user reach a scanner that will fail with sdkNotInitialized. A failed initialize() call itself returns initializationFailed or a license or connection error (see the tread error mapping).
  • Do not re-initialize on normal foreground and background transitions. Re-run the step only if a license key changed or the first attempt failed.
  • Tire Sidewall is part of the Tire Tread SDK and uses a client ID provided by Anyline, separate from your license key. Pass it to the scanner and the SDK handles authentication for you. If your client ID is not yet provisioned for sidewall, contact Anyline.
  • Check the platform minimums before you start. Each SDK states its own minimum Android API level and iOS version on its getting-started page, linked below. An app that uses both SDKs has to satisfy the stricter of the two, and the Tire Tread SDK wrappers for Flutter and React Native carry their own iOS floor. Use the latest Tire Tread SDK release for the sidewall scanner. Your app may set higher floors than the SDKs require, but not lower ones.
  • AnylineTireTread.isDeviceSupported() does not need the SDK to be initialized, so call it at any time and gate the tread entry point on the result. On Android, pass an Activity as the context so the SDK can request camera permission for you; on iOS the check verifies the minimum OS version.

Relevant documentation: Tire Tread SDK initialization · Tire Tread SDK device support check · Mobile SDK getting started (Android) · Mobile SDK getting started (iOS) · Flutter plugin getting started.

3
App Orchestration

Correlate and link the elements of your inspection flow within the app

This is intentionally called out early to avoid it being overlooked. It's good practice to establish these foundations upfront. Defining the inspection structure, tire positioning, and correlation ID strategy early helps keep everything consistent later, especially for retries, asynchronous tread handling, and Enrich grouping.

App orchestration
1 inspection
Tire positions and progress
measurementUUID to tire position
Screen progression and retries
Inspection data enrichment
Shared inspection context
Per-vehicle correlation IDs
1 Enrich call per vehicle ID
Per-tire correlation IDs
1 Enrich call per tire

Vehicle Inspection Data Orchestration

This section defines app implementation, inspection correlation, and inspection enrichment.

App Implementation

Your app keeps the inspection together

Use app state to group vehicle scans, tire scans, retries, and async tread retrieval into one inspection flow.

  • Inspection session lifecycle
  • Tire position and per-wheel progress
  • Screen progression and retry behavior
  • Run tire identification (tire size or sidewall) before Tire Tread for each wheel, so the scanned width can be passed into the tread config on Android
  • Map every measurementUUID back to tire position for async tire tread results
Inspection correlation

Your integration tracks event relationships

This defines how your data is mapped into a single transaction.

  • Create and assign one vehicle-level correlationId
  • Create and assign one tire-level correlationId per tire
  • measurementUUID mapped to tire position for async tire tread results
  • Carry one customer workflow, inspection, or session number as customerTransactionNumber
Inspection enrichment

Follow one strategy consistently across the inspection

We recommend a consistent Enrich relationship strategy so one inspection can be reconstructed cleanly across vehicle and tire flows.

  • Use correlationId as the Enrich identifier
  • Reuse the vehicle correlationId for vehicle Enrich
  • Reuse each tire correlationId for that tire Enrich (Recommended: send one Enrich call per tire)
  • Include shared businessInformation and use your workflow, inspection, or session number as customerTransactionNumber
  • For tire tread, you can also send additionalContext with tirePosition from the SDK
4
Vehicle Flow

Implement vehicle identification

Add license plate scanning

  • Load the region-specific config before opening the scan.
  • US and Canada use crop padding values.

Relevant documentation: Android license plate · iOS license plate.

Start from this license plate config

Europe starter
Config snippet

Start from this VIN config

Check digit by region
Config snippet

Relevant documentation: Android VIN · iOS VIN.

Combine VIN and barcode in one flow

  • Use a parallel-first VIN and barcode configuration when both are needed.
  • Reject candidates that are not 17 characters long after extraction.
  • Reject candidates containing O, I, or Q.
  • For 18 or 19 characters, strip the first character and keep the next 17.
  • For 20 characters, strip the first two characters and keep the next 17.
  • For longer payloads, try the first 17 characters as a fallback.

Relevant documentation: Android VIN · iOS VIN · Android barcode · iOS barcode.

Start from this VIN plus barcode config

Parallel composite
Config snippet

Start from this barcode config

  • Use the barcode scan configuration for inspection-level case ID data.
Config snippet

Relevant documentation: Android barcode · iOS barcode.

5
Tire Flow

Implement tire identification

Note: We recommend scanning tire size before tread. On Android, tire width is required - without it, users will be prompted to select it manually.

Core tire sidewall flow

1. Create the tire correlationId

Create one tire-level correlationId before the sidewall capture starts, and keep reusing that same identifier for that tire.

2. Check device support

Call isSupported() before showing the sidewall entry point. On Android, offer resolvePlayServices() when the failure is user-resolvable, and hide the entry point when it is not.

3. Launch the SDK sidewall scanner

Call scan() with your Anyline client ID and the correlationId. The scanner guides the user, captures automatically, and uploads the image for you.

4. Handle the single capture result

The scan returns exactly one result: Completed, Aborted, or Failed. Attach the parsed result and captured image to the correct tire position.

5. Offer a clear retry on failure

On a Failed result, show a recovery sheet that relaunches the scanner or lets the user skip, instead of continuing with a broken tire state.

Integrate the SDK sidewall scanner

Sidewall capture is handled by the Tire Sidewall Scanner in the Tire Tread SDK (v15.3.3 or later). The scanner opens a full-screen guided camera experience: it detects the tire on-device, guides the user into position, captures automatically once the sidewall is correctly framed, and uploads the image to the Anyline backend for extraction. There is no manual shutter, and no capture screen for you to build.

Migrating from the Tire Sidewall Cloud API: remove your existing capture screen, image upload call, and related camera handling entirely, then integrate the scanner described here. The direct Cloud API integration is superseded and its dedicated documentation page has been retired.

Tire Sidewall SDK scanner with on-screen alignment guidance and automatic capture
Reference capture flow. The SDK scanner guides alignment on screen and captures automatically once the guidance turns green.

What your app implements

  • Check device support with isSupported() before showing the sidewall entry point. It does not need the SDK to be initialized, so it can run before the setup step completes. On Android, when the result is not user-resolvable, hide the sidewall entry point, show a short unsupported-device message, and let the rest of the inspection continue; when it is resolvable, call resolvePlayServices() and check again. The Android scanner needs Google Play Services, so emulators without Google Play and devices without Google services are reported as unsupported. On iOS the check always reports the device as supported. In the Flutter plugin, isSupported() never throws: it returns a TireSidewallSupport with supported, userResolvable and an optional error (playServicesUnavailable or internalError).
  • Launch the capture by passing your Anyline client ID to scan() (see Initialize both SDKs in one setup step). The client ID is only validated when the image is uploaded, so a missing or wrong value surfaces as INVALID_LICENSE after the user has already captured. Verify the client ID in your release configuration before shipping.
  • Pass the tire-level correlationId through the scanner config. It must be a version-4 UUID; an invalid value fails the scan with INVALID_UUID before the scanner opens.
  • Handle camera permission: the scanner requests it at runtime, and on iOS your app needs an NSCameraUsageDescription entry in Info.plist.
  • If you support languages beyond English, override the on-screen guidance strings through the texts config. Everything else about capture (resolution, framing, timing) is managed by the SDK and is intentionally not configurable.

Relevant documentation: Tire Sidewall Scanner · Tire Tread SDK getting started.

Handle the capture result

Each scan returns exactly one result (a callback on the main thread natively, a Future in Flutter) with one of three outcomes. Handle all three explicitly rather than treating anything that is not a success as a generic error.

Completed

  • Parse the returned resultJson and attach it to the correct tire position (see the response mapping below).
  • Persist the returned image (imageBytes; upright, display-ready) if the sidewall photo needs to be available later, for example for inspection history or report generation.
  • Check the lighting value on the completed result (lighting on TswScanCompleted; scanMetadata.environmentLighting in the native SDKs): when it reports Dark or Bright, we recommend showing a suboptimal-lighting hint on the result screen so users understand why extracted values may be incomplete.

Aborted

  • The user dismissed the scanner before capture. Return to the screen the capture started from without showing an error.

Failed

  • The result carries a structured error (code, type, message). For retryable errors, show a recovery sheet with two actions: a primary action that relaunches the scanner for the same tire, and a secondary action that skips sidewall data for that tire. For configuration errors such as INVALID_LICENSE, show a non-retryable message that points the user to their administrator (see the error mapping below).
  • When logging failures to your crash reporter, log the whole error, not only the message: it also carries a debug object (exception type, raw message, HTTP status) that support needs. In Flutter, log error.toMap(); SdkError has no readable toString(). In the native SDKs, log result.error of the Failed result.

Relevant documentation: Tire Sidewall Scanner results and errors · Tire Tread SDK error handling.

Advanced Recommended sidewall error-message approach
Recommended approach

Group the sidewall error codes into five user-facing messages: three retryable messages for connection, processing, and unexpected failures, one non-retryable message for configuration issues that tells the user to contact their administrator, and one device-support message from the pre-flight check. Never show raw error codes to users; report them to your crash reporter instead.

Sidewall capture error codes

Codes are shown in their native and React Native spelling. The Flutter plugin uses the camelCase ErrorCode equivalents, for example invalidLicense or playServicesUnavailable.

Code UI title Recommended handling
NO_CONNECTION
TIMEOUT		 No connection "You appear to be offline, or the upload took too long. Check your connection and try again." Offer Capture again and Skip.
UPLOAD_FAILED Couldn't read the tire "Something went wrong while processing your photo. Try again with the full sidewall in frame and good lighting." Offer Capture again and Skip. This includes captures where the tire was only partly visible.
INTERNAL_ERROR
Flutter also: unknownError		 Something went wrong "Something went wrong while opening the camera. Try again." Offer Capture again and Skip. Covers camera start failures and on-device model load failures. Report to your crash reporter.
isSupported() reports the device as not supported
or, at scan time, PLAY_SERVICES_UNAVAILABLE		 Capture unavailable on this device Android only, shown before the scanner opens. Resolvable: "Sidewall capture needs an up-to-date Google Play Services. Update it, then try again." Offer Update and Skip. Not resolvable: "Sidewall capture isn't supported on this device." Offer Skip only.
CAMERA_PERMISSION_DENIED Camera access needed Prompt for camera permission before launching the scanner, and link to system settings when the permission was permanently denied.
INVALID_LICENSE Capture unavailable "Tire sidewall capture isn't available right now. Please contact your administrator." Offer Skip only, no retry: the client ID is missing, invalid, or not authorized, so retrying cannot succeed. Verify the client ID and that Anyline has provisioned it for sidewall, and alert your team through crash reporting.
INVALID_UUID Capture unavailable Integration bug: the supplied correlationId is not a valid version-4 UUID. Fix the identifier generation in your code. If it escapes to production, show the same non-retryable administrator message.
ALREADY_RUNNING Not user-facing A sidewall capture is already in progress. Guard the entry point against double taps instead of surfacing an error.
INVALID_ARGUMENT Not user-facing Integration bug in the Flutter or React Native app: the plugin found no Activity or view controller to open the scanner from. Launch the scan only from a visible screen.

Relevant documentation: Tire Sidewall Scanner error codes.

Add tire-size scanning

  • Add the Tire Size scan config to the tire flow.
  • Default the Tire Size scanner to landscape orientation. The defaultOrientation property applies to cross platform plugin only. For native iOS and Android integrations, lock the screen to landscape orientation in your app code before starting this scanner.
  • Default the torch / flash to on for this scan.

Start from this tire-size config

Config snippet

Relevant documentation: Android tire size · iOS tire size · iOS UI feedback configuration.

Start from this DOT / TIN config

Universal default

Use Production date mode unless you have a specific business need to show or process the full DOT or TIN string. The mode sets validateProductionDate to true, so the scanner only accepts a TIN whose production date is valid; the SDK still returns the full string, and your app displays the productionDate field alone (see the response mapping below).

Default the DOT / TIN scanner to landscape orientation. The defaultOrientation property applies to cross platform plugin only. For native iOS and Android integrations, lock the screen to landscape orientation in your app code before starting this scanner.

Default the torch / flash to on for this scan.

Config snippet

Relevant documentation: Android TIN · iOS TIN.

In most customer flows, production date is the only value that needs to be displayed. Reserve full DOT or TIN mode for cases where the complete string is required for a specific downstream workflow.

Advanced Map tire scan response fields

Map tire scan response fields

These mappings are useful if you want to label tire-identification values in your own result views.

DOT / TIN

Use the selected DOT mode

Label Response key Use when
DOT / TIN tinResult.resultPrettified Full DOT or TIN mode is active.
Production date tinResult.productionDate Production-date mode is active.

Show only the field that matches the selected mode. For most integrations, production date stays the default.

Tire size

Map the tire-size response

Label Response key Related values
Tire size tireSizeResult.prettifiedString.text Load: tireSizeResult.loadIndex.text
Speed: tireSizeResult.speedRating.text

Use the prettified tire-size string in the result UI and display load and speed as separate fields.

Tire Sidewall

Map the sidewall response fields

Parse the resultJson string from the Completed capture result. Keys are top-level unless prefixed with details. Fields the scanner could not read are omitted or null, so map defensively.

Label Response key Use in UI
Make make Fill the tire make field directly.
Model model Fill the tire model field directly.
Model group modelGroup Shorter model family name, returned when one exists for the model.
Tire size size Reuse as the displayed tire size after validating the format.
Load index details.loadIndex Map to the display value shown in the app.
Speed rating details.speedRating Map to the display value shown in the app.
Runflat details.runflat Show as a runflat badge or attribute when true. Returned from Tire Tread SDK 15.4.0; a missing value means unknown, not false.
3PMSF details.threePeakMountainSnowflake Three-Peak Mountain Snowflake winter certification; show as a badge when true. Returned from Tire Tread SDK 15.4.0; a missing value means unknown, not false.
M+S details.mudAndSnow Mud-and-snow marking; show as a badge when true. Returned from Tire Tread SDK 15.4.0; a missing value means unknown, not false.
DOT / TIN dot Show this field when full DOT mode is selected.
Production date details.productionDateYearMonth Show this field when production-date mode is selected.
resultJson sample 
{
  "make": "GOODYEAR",
  "model": "ASSURANCE COMFORTDRIVE",
  "modelGroup": "ASSURANCE",
  "size": "225/55 R 17 97V",
  "dot": "DOT 4B9R FW2X 3223",
  "details": {
    "loadIndex": "97",
    "speedRating": "V",
    "productionDateWeekYear": "3223",
    "productionDateYearMonth": "2023/08",
    "tireAgeInYearsRoundedDown": 3,
    "runflat": false,
    "threePeakMountainSnowflake": false,
    "mudAndSnow": true
  }
}

Derive load and speed display values from the returned raw fields and map them to region-appropriate units in the app.

Start from this load and speed mapping

Lookup example

If you display load and speed in your result UI, map the raw loadIndex and speedRating values to region-appropriate display units. The example below shows the same mapping pattern used in the app implementation.

Lookup example 
{
  "loadIndexToDisplay": {
    "91": { "metric": "615 kg", "imperial": "1356 lb" },
    "95": { "metric": "690 kg", "imperial": "1520 lb" },
    "98": { "metric": "750 kg", "imperial": "1650 lb" },
    "100": { "metric": "800 kg", "imperial": "1800 lb" },
    "104": { "metric": "900 kg", "imperial": "2000 lb" },
    "109": { "metric": "1030 kg", "imperial": "2270 lb" },
    "120": { "metric": "1400 kg", "imperial": "3100 lb" }
  },
  "speedRatingToDisplay": {
    "Q": { "metric": "160 km/h", "imperial": "100 mph" },
    "S": { "metric": "180 km/h", "imperial": "112 mph" },
    "T": { "metric": "190 km/h", "imperial": "118 mph" },
    "H": { "metric": "210 km/h", "imperial": "130 mph" },
    "V": { "metric": "240 km/h", "imperial": "149 mph" },
    "W": { "metric": "270 km/h", "imperial": "168 mph" },
    "Y": { "metric": "300 km/h", "imperial": "186 mph" }
  }
}

Extend this starter with the full lookup set you support in your app so every returned load index and speed rating resolves to a clear display value.

Optional Optional Tire Sidewall onboarding assets and card copy

Optional Tire Sidewall onboarding assets and card copy

We recommend a short onboarding flow before the first sidewall capture, using the three-card structure below. Even though the SDK guides the capture itself, the cards set expectations for the hands-off experience. Re-show them after a failed capture so users are re-oriented before retrying.

Tire Sidewall onboarding card 1 sample UI
Card 1 sample UI. Example export for the “Get ready” onboarding card before the sidewall capture starts.
Tire Sidewall onboarding card 2 sample UI
Card 2 sample UI. Example export for the “Straight position” card that introduces the on-screen alignment guidance.
Tire Sidewall onboarding card 3 sample UI
Card 3 sample UI. Example export for the “Hold steady” card explaining that the scanner captures automatically.
Card 1

Get ready

Prepare for the scan

  • Keep the tire straight, avoid angles.
  • Use bright, even lighting.
  • Keep the tire close, sharp and fully visible.
Card 2

Straight position

Frame center, stay front facing

  • Follow on-screen guidance.
  • Orange or red means adjust, green means you're set.
  • Avoid top view, kneel if needed.
Card 3

Hold steady

The app captures for you

  • Hold your phone steady.
  • Watch on-screen guidance turn green.
  • It captures automatically, no tap needed.
6
Tire Tread

Implement tire tread scan flow and async result handling

Important: On Android, the Tire Tread SDK needs a tire width. If your flow includes Tire Identification, pass the scanned width into the tread config to give users a seamless experience. Without it, the SDK falls back to a built-in width-selection sheet.

Core tire tread flow

1. Tire correlation ID

Create one tire-level correlationId and reuse that same identifier for the sidewall, DOT / TIN, tire size, Tire Tread, and Enrich flow of that tire.

2. Send tire tread additionalContext

Use additionalContext to carry the tire position for the Tire Tread measurement. Keep this separate from the tire correlation strategy.

3. Store the async tire tread handle

As soon as the SDK returns a measurementUUID, map it back to the same tire position so later async results update the correct wheel.

4. Retrieve the async tire tread result

Fetch the result by measurementUUID and apply it to the matching tire state instead of treating the scan response as the final tread payload.

5. Enrich that tire

After the tire scan data is ready, send the Enrich call with the same tire correlationId plus shared metadata such as shop, employee, and customerTransactionNumber.

Start by defining your tire tread configuration using the JSON schema

  • Set uiConfig.measurementSystem (Metric or Imperial, default Metric) so the scan flow, thresholds, editing UI, and any output all use the same unit system.
  • Set up the tire tread results config based on the use case: use the global result for most flows, and only show zone-level details when uneven wear needs to be highlighted.

Relevant documentation: Tire Tread full JSON schema. Tire Tread Flutter component.

Choose the tire tread result model for your use case

Use the global result for most flows.

Global value (recommended)

Default for most implementations. Uses a single overall tread-depth value calculated from all measurements across the tire.

  • Provides the most stable and representative result.
  • Best suited for customer-facing output and consistent reporting.
  • Recommended for the majority of use cases.
Zonal values (advanced)

Use for detailed inspection or uneven wear analysis.

  • Intended for technician workflows and diagnostic scenarios.
  • May be influenced by specific patterns or irregular wear distribution, and should be interpreted in context.
Lowest value

Uses only the lowest tread depth detected across all measurements. Use only if your product intentionally wants the worst-case indicator.

  • May be influenced by specific patterns or irregular wear distribution, and should be interpreted in context.

Handle async retrieval and tread scan errors

  • Store each returned measurementUUID immediately and map it back to the matching wheel position.
  • Fetch tread results asynchronously with getResult(measurementUUID, timeoutSeconds) and update the correct tire state when the result returns. The call waits up to timeoutSeconds (default 60) for processing to finish. Results are guaranteed to be retrievable for at least 24 hours after the scan; fetch and persist them within that window.
  • Map SDK error states into user-facing UI states and messages.
  • Preserve both scanned values and user-edited values.

Relevant documentation: Tire Tread Flutter error codes · Flutter User Corrected Values.

Advanced Recommended error-message approach
Recommended approach

Use these mappings as the default pattern unless your product needs different support language, escalation rules, or recovery actions.

Scan error codes

The Flutter plugin reports a failed scan as a ScanFailed outcome carrying an SdkError with code (ErrorCode), type (ErrorType) and message. Other calls such as initialize(), getResult() and getHeatMap() throw a PlatformException whose code is the native upper-case name of the error code, for example INVALID_LICENSE or CAMERA_PERMISSION_DENIED, not the camelCase ErrorCode value. Map on SdkError.code for scan outcomes and on the upper-case PlatformException.code for all other calls. The table covers every ErrorCode of the plugin. On a ScanFailed outcome, a code the plugin does not recognize arrives as unknownError; for a PlatformException, treat any code you do not map as the catch-all row.

Type and code UI title UI message
licenseError
invalidLicense, licenseKeyForbidden, sdkNotVerified		 Invalid license Your license is missing, expired, or not valid for this version of the app. Contact your account manager or IT team to renew or reactivate your license.
configError
invalidArgument		 Invalid configuration The app is not configured correctly. Please contact your support team to resolve this.
configError
cameraPermissionDenied		 Camera access needed Tread scanning needs the camera. Enable camera access for this app in your device settings, then try again. Link to system settings when the permission was permanently denied. On Android, isDeviceSupported() throws a PlatformException with code CAMERA_PERMISSION_DENIED when the permission is not granted. It can only show the permission prompt if your MainActivity extends FlutterFragmentActivity; with the default FlutterActivity the call fails without prompting.
networkError
noConnection		 No connection The device has no network access.
networkError
uploadFailed		 Upload failed It looks like some tire images didn’t reach our server. Please ensure your internet connection is stable and try again.
networkError
timeout		 Server not responding The server took too long to respond. Check your connection and try again. If this keeps happening, contact support.
scanError
sdkNotInitialized		 App not ready A scan was started before the app finished loading. Wait for the app to fully load, then try your scan again.
scanError
initializationFailed		 App failed to start The app could not complete its startup process. Restart the app. If the problem continues, contact your IT team.
scanError
sessionCreationFailed		 Could not start scan session The app was unable to open a new measurement session. Restart the app and try again.
scanError
alreadyRunning		 Scan already in progress Another scan is currently running. Wait for the current scan to finish before starting a new one.
scanError
playServicesUnavailable		 Sidewall capture unavailable on this device Sidewall capture needs Google Play Services. Update it from the Play Store, then try again. Raised by the sidewall scanner, not by tread. Avoid it with the sidewall device check; see the sidewall error table.
scanError
measurementError		 Processing error We encountered an issue analyzing your tire. Please repeat the measurement slowly. If the problem persists, contact our support team for assistance.
scanError
internalError, unknownError		 Something went wrong An unexpected error occurred in the app. Restart the app and try again. If the issue continues, report it to support.
resultError
invalidUuid		 Measurement not found The scan ID doesn't match any record on the server. Re-run the scan or check your scan history for the correct record.
resultError
resultError		 Result unavailable The server could not return the measurement result. Try fetching the result again. If it fails, rescan the tire.
resultError
heatmapError		 Heatmap unavailable The tread heatmap could not be generated. The measurement values are still valid; retry loading the heatmap or continue without it.

Relevant documentation: Tire Tread Flutter plugin · Tire Tread SDK error handling.

Recommended implementation: show these messages inline for the affected tire and keep the recovery action explicit, for example Scan again.

Optional Optional tire tread onboarding assets and card copy

Optional tire tread onboarding assets and card copy

We recommend a guided onboarding before the first tread measurement, reuse the reference videos and structure provided below.

tire tread learning card sample UI
Learning-card sample UI. Local example export for the “Get ready” tread training card.
tire tread onboarding tutorial sample UI
Full-screen tutorial sample UI. Local example export for the full-screen prompt shown before tread capture starts.
Download tire tread learning-card video Download tire tread opening-scan video
Card 1

Get ready

Prepare for the scan

  • Keep the right distance and angle. Hold phone 20 cm from the tire tread and parallel to the tread surface.
  • Scan smoothly across the tread. Move in an arc from shoulder to shoulder for 7 seconds, focusing only on the tread.
  • Keep tire close, sharp and fully visible. Keep the camera clear of backlighting and obstructions like mud flaps.
Card 2

Capture prompt

Full-screen tutorial sample UI.

  • Record very slowly for 7 seconds.
7
Enrich and Reporting

Group inspection data and enrich with additional information

Send one Enrich API payload per vehicle and per tire

  • Send one Enrich API payload per vehicle and one per tire, including additional context such as tire position.
  • Keep the customerTransactionNumber stable across the full inspection flow.
  • Include any business metadata required by your reporting or backend systems, in addition to the inspection ID.

Get an Insights API token first

  • Enrich is part of the Insights API and needs its own Bearer token. Request it from the Anyline token endpoint with your client ID and api=insights-api.
  • Only the client ID is on the device. Ship the client ID with the app. It is the only value the Insights API token request needs.
  • Tokens come from the Anyline token endpoint. It manages the Insights API client credentials for you and returns a token for your client ID. Do not call the Auth0 token endpoint from the app.
  • Request the token right before the API call. Get a token from the Anyline token endpoint, then call the Insights API. Do not assume a fixed lifetime: the endpoint may hand you a token it already holds, so if you keep one, check its exp claim before reusing it.

Because Anyline manages the client credentials behind its token endpoint, your app only holds the client ID and the tokens it receives. Security guidance for credentials and tokens: Anyline documentation, Insights API authentication, Understanding the Risks.

Token request and Enrich call 
# 1. Get an Insights API token from the Anyline token endpoint, right before the Enrich call
curl --request POST \
  --url 'https://auth-m2m.anyline.com/api/token?api=insights-api&client=YOUR_CLIENT_ID'

Response
{ "access_token": "eyJ..." }

# 2. Send the Enrich payload with the token
curl --request POST \
  --url https://insights-api.anyline.com/v1/enrich \
  --header 'Authorization: Bearer YOUR_ACCESS_TOKEN' \
  --header 'Content-Type: application/json' \
  --data '{
    "correlationId": "YOUR_VEHICLE_OR_TIRE_CORRELATION_ID",
    "enriched": {
      "businessInformation": {
        "customerTransactionNumber": "INSPECTION-12345",
        "shopId": "shop-001",
        "employeeId": "emp-042"
      }
    }
  }'

Response
{ "eventId": "..." }
Diagram Inspection flow and Enrich API grouping Sequence diagram — vehicle and per-tire correlationId strategy.
Sequence diagram showing vehicle and per-tire scan events with correlationId grouping and Enrich API calls

Include shop name, employee or technician identifier, your workflow, inspection, or session number, and inspection ID when available. Some partner payload fields may be contractually optional, but sending this context makes inspection traceability and support workflows significantly clearer.

Do not model this as one aggregate inspection payload with nested tires. The implementation flow is vehicle correlation on one side, per-tire correlation on the other side, and a shared inspection identifier carried through businessInformation.

Reference Enrich API payload schema Request body fields for application/json.

enriched (required, object)

Nested fields supported by the Enrich API.

businessInformation (required, object)

All provided fields will be updated. Fields not provided will not be updated.

Field Type Notes
customerTransactionNumber string Transaction number of your customer.
deviceId string ID of the device used for the scan event(s).
employeeId string ID of the employee associated with the scan event(s).
shopId string ID of the shop associated with the scan event(s).
shopName string Name of the shop associated with the scan event(s).
trailerNumber string Trailer associated with the scan event(s).
Scan event identifier, provide exactly one

Exactly one of the three fields below must be provided on each Enrich call to bind the payload to its scan event.

Field Type Notes
correlationId string correlationId associated with the scan event(s).
transactionId string transactionId associated with the scan event.
measurementUUID string measurementUUID associated with the scan event.

What you get back

  • Enriched scans appear in your Insights Dashboard, where the businessInformation fields you send become filters and groupings for your reports.
  • Per-tire tread resources (cross-section image, tire image, scan animation) are available through the Insights TTR API by measurementUUID.

Relevant documentation: Insights API · Insights API authentication · Enrich API · Insights TTR API.

8
Optional Optimization

Optimize Mobile SDK size and send tread result feedback

Mobile SDK size reduction

  • Size reduction applies to the Mobile SDK only: package just the Mobile SDK modules your selected features use. The Tire Tread SDK (tread and sidewall) has no module trimming.
  • On Android, keep the required modules in the packaging configuration.
  • On iOS, remove unused Anyline modules from AnylineResources.bundle during build.

Relevant documentation: Reduce SDK size (Android) · Reduce SDK size (iOS) · Reducing the size of the SDK.

Tread result feedback

  • If a technician corrects tread values, send the corrected regions back with sendTreadDepthResultFeedback, keyed by measurementUUID. Only the regions the SDK returned can be corrected.
  • Comment text is a separate call (sendCommentFeedback natively, sendFeedbackComment in the Flutter plugin); do not bundle it into the region feedback.
  • Confirm the exact trigger point in the UI for sending feedback, for example when the edited value is saved.

Relevant documentation: User-corrected regional values · User comments.

9
Final Checklist

Ensure key implementation steps have been followed

Implementation checklist

This checklist updates from the selected features and market.

0 of 0 complete

Frequent implementation pitfalls

  • Reusing one correlationId across all tires instead of generating one per tire.
  • Initializing the SDKs too late, more often than needed, or opening scan screens after one of the two initializations failed.
  • Not saving the measurementUUID before async tire tread result retrieval.
  • Treating region-specific configs as interchangeable.
  • Setting DOT / TIN to full mode instead of production date when the full string is not actually required.
  • Choosing a tread result mode that does not match product expectations.