When Your Mobility Platform Won't Talk to a New Fleet Partner: What to Fix First

You're staring at an error log that basically says 'no.' The new fleet partner sent their API docs a week ago. Your mobility platform—the one you pay six figures a year for—just throws a 400. Or a 500. Or a 403 with a message that basically means 'we don't support that region.'

This isn't a hypothetical. It happens when your platform vendor's roadmap doesn't match your growth. Maybe they've deprecated the endpoint you need. Maybe the new partner uses a protocol the platform never heard of. Or maybe—the worst case—the platform's contract says 'no third-party integrations without our approval.' Now you've got a decision to make, and the clock's ticking. Every day the integration is down costs you money, driver goodwill, or both. This article walks you through what to fix first, who decides, and how to avoid making things worse.

Who Decides and How Fast? The First 24 Hours

Decision authority: CTO vs VP of Operations vs integration lead

The first hour after your platform stops talking to a new fleet partner is chaos—but the real bottleneck isn't technical. It's a name. Someone has to own the call. I have seen teams waste an entire day ping-ponging between a CTO who thinks this is a procurement problem and a VP of Operations who assumes engineering will just handle it. Wrong order. The CTO owns the timeline but rarely understands the business impact of a delayed partner go-live; the VP of Operations feels the revenue bleed but can't authorize a middleware spend. That gap costs you more than any coding error ever will. The fix: name exactly one person as the integration decision-maker before anyone touches a config file. No committees. No "let's loop in legal later." That person gets 24 hours to declare whether the blockage is solvable in-house or requires an external tool.

Time pressure: what changes if the partner is already live vs still in onboarding

A partner already dispatching trips on your platform—that's a fire. You have minutes, not hours, to decide whether to patch with a lightweight API proxy or fall back to manual dispatch while engineering builds a proper adapter. The catch is that most teams pick the first option that stops the alert noise, and six months later they're still running on that brittle proxy with no migration plan. If the partner is still in onboarding, you have a different luxury: you can kill the integration entirely or renegotiate the technical scope. That sounds fine until the business development team has already promised the partner a "seamless launch" next week. Pressure distorts judgment—I've watched operations leads approve a custom adapter build under a fake deadline, only to discover the partner's API didn't even support the required endpoints.

“We spent 40 hours building an adapter for a partner whose API returned 200s for empty payloads—no one tested the contract first.”

— Integration lead at a mid-market mobility operator, 2024

Initial triage: is it a bug, a contract block, or a missing feature?

The first triage question is painfully simple: does the partner's API work at all? Most teams skip this. They blame the platform vendor's lock-in before verifying that the partner's endpoint returns a 500 on a basic auth handshake. Run a cURL test. If the call succeeds but data doesn't flow, the problem is mapping—your platform expects a driver_id field; the partner sends operator_ref. That's a feature gap, not a lock-in. If the call fails on authentication, check whether your platform's credential store can even hold the partner's token format. I've seen a vendor lock-in panic turn into a ten-minute config fix. The real pitfall is the contract block: your platform's license terms prohibit third-party integrations without a premium tier upgrade. That's not a technical problem—it's a purchasing decision disguised as a bug. Triage in this order: test connectivity, test data shape, review terms. Most teams reverse that order and burn three days negotiating before running a single API call.

Your Real Options (There Are More Than Two)

API proxy or gateway as a stopgap

Your fleet partner speaks REST. Your platform only understands SOAP. In the first 48 hours someone will suggest a proxy layer — a lightweight API gateway that sits between the two and translates requests on the fly. I have seen teams wire this up in a weekend using Kong or Tyk, mapping endpoints one by one. It works. Until it doesn't. The gateway becomes a black box that everyone fears touching, and every new field in the payload requires a rule rewrite. That said — for a three-month bridge while you evaluate permanent solutions, a proxy beats doing nothing. The catch: you own the translation logic, not the platform vendor, so when something breaks at 2 AM your ops team gets the call, not theirs.

Middleware integration platform (iPaaS) for transport translation

Most teams skip this option because they think iPaaS means Workday-to-Salesforce HR data syncs. Wrong assumption. A good integration platform — think Boomi, MuleSoft, or even n8n for smaller shops — can abstract the differences between your mobility core and a new fleet provider's API without requiring code in your main application. We fixed a particularly nasty vendor lock-in situation this exact way: the fleet partner used gRPC, the platform expected JSON over HTTP, and the middleware handled the serialization and retry logic. The trade-off? Monthly subscription cost that scales with message volume, and you inherit the middleware vendor's latency. One rhetorical question: can your margins absorb a 200-millisecond per-call overhead on every geolocation ping? Some fleets can. Others bleed.

Vendor-supported extension points (where they exist)

The platform vendor might already offer plugin hooks, custom event listeners, or a connector SDK. Most people never check — they assume vendor lock-in means zero flexibility. Not always true. One mobility platform I worked with had a hidden 'driver assignment interceptor' that let us inject a custom routing call to a new fleet partner's dispatch API. The tricky part is reading the fine print: extension points often come with deprecation windows of 12 months or less, and the vendor can change the contract mid-cycle. A blockquote here feels right:

'We used the vendor's custom adapter slot for six months. Then a platform update silently broke the interface. No warning. No rollback.'

— CTO, a regional logistics provider that lost three integration weeks

That pain is real. If you go this route, insist on a written compatibility commitment for at least two major platform versions — not just a handshake from the account manager.

Custom adapter built in-house or by a third-party integrator

Your last real option is the one nobody wants to budget for: a bespoke adapter that lives inside your deployment, translates every field, handles auth differences, and exposes a stable contract to your application. I have seen a team of two engineers build this in three weeks for a last-mile delivery pivot. They mapped driver status codes, vehicle telemetry, and billing metadata between a legacy XML schema and a modern GraphQL endpoint. The cost was roughly what the company spent on one month of middleware subscription — but they owned the code. The pitfall: maintenance debt. Every platform upgrade, every new fleet partner, every edge case becomes your problem. No vendor to blame. That clarity can be liberating or terrifying — depends on your team's tolerance for owning the seam.

Field note: mobility plans crack at handoff.

Field note: mobility plans crack at handoff.

What to Compare Before Picking a Path

Time to production: hours vs weeks vs months

The first question I ask every team is simple: How fast does the next partner need to be live? That deadline—not the feature list—should drive your choice. A quick API proxy can often stitch two endpoints together in a weekend if both sides speak REST and your auth models align. But if the new fleet partner uses legacy SOAP or a custom binary protocol? That same weekend fix turns into three weeks of mapping XML schemas. I have seen a mobility operator burn six weeks on a middleware deployment because they assumed “generic integration layer” meant zero configuration. Wrong order. The reality: time-to-production varies by a factor of 100x depending on protocol mismatch alone.

The catch is that most vendors won’t tell you their integration latency upfront. You have to poke. Ask the new partner for one sample payload—then test whether your existing platform parses it without translation. That single test often reveals whether you need hours of regex tweaks or months of adapter engineering.

Ongoing maintenance burden: who patches when versions change

What usually breaks first is the authentication handshake—not the data schema. Your mobility platform pushes a minor security update, and suddenly your custom adapter returns 403 errors. Who fixes that? If you built the adapter yourself, your team owns the patch. If you used middleware, the middleware vendor owns the connector layer—but you still absorb the cost of testing and deploying the fix into production. That distinction matters more than most teams realize.

I have watched a fleet integration fail repeatedly because the third-party middleware vendor treated the API update as “out of scope” in their support contract. The operator paid twice: once for the middleware license, once for emergency consulting to patch what the middleware should have handled. So ask bluntly: Who absorbs the cost when a schema field gets deprecated? If the answer is vague, that’s a red flag.

Contractual risk: does the platform vendor allow middleware or custom code?

Here is the trap that catches expansion teams off guard. Your existing mobility platform’s terms of service may explicitly prohibit third-party middleware sitting between their API and your fleet partners. I have seen contracts that mandate “direct connection only” to limit liability and support scope. Violate that clause, and the vendor can terminate your license—or refuse to help when something fails. The tricky bit is that these restrictions often hide in appendixes titled “Data Security Addendum” or “Integration Policy.”

Most teams skip this: send your procurement team digging for two specific phrases—“intermediary” and “authorized connector.” If either appears, your middle-path options shrink fast. That said, some platforms permit custom adapters as long as you sign an indemnity waiver. Know this before you pick a path, or you pick a path that gets shut down mid-deployment.

Future-proofing: will this fix work with the next partner too?

Building for one partner is tactical. Building for three is structural. If your current integration fix can't be reused for the next fleet provider, you will repeat the pain in six months. Ask: Does the adapter abstract the differences, or does it hard-code the partner’s quirks? An API proxy that directly maps your platform’s geofence fields to partner-specific coordinate formats is fast—but brittle. A middleware layer that normalizes to a common internal schema takes longer upfront, yet survives partner swaps with zero code changes.

That trade-off stings most when you expand to a second market two quarters later. I have seen a company re-implement their entire integration because the original custom adapter assumed one authentication method and one data model. The next partner ran OAuth 2.0 with a nested JSON structure—everything broke. Future-proofing means accepting more complexity now to avoid a rewrite later. Not glamorous, but cheaper.

“The cost of a quick fix compounds. The cost of a modular fix amortizes. Choose which debt you want to carry.”

— Senior integration architect at a three-region mobility operator

So before you evaluate tools or architectures, evaluate these four variables first. Run each option through the same filter: time, maintenance liability, contract boundaries, and reusability. The option that scores highest across all four is rarely the fastest—but it's the one that won't blow up six months from now when a new partner calls.

Trade-Offs at a Glance: API Proxy vs Middleware vs Custom Adapter

API proxy: fast to deploy, but fragile on data format changes

You can spin up an API proxy in an afternoon. A reverse proxy sits between your platform and the new fleet partner, translating endpoint URLs and maybe remapping a few header fields. That sounds fast—and it's, for the first integration. The tricky part is what happens when either side updates their schema. A new required field in the partner’s order payload? The proxy silently drops it, and your dispatch team starts wondering why half the trips show “location unknown.” I fixed one of these for a ride-hail operator in Berlin last year: their proxy had been running for eight months, then the fleet partner added a vehicle_range_meters field. The proxy didn’t forward it. No error. No log. Just a slow leak of failed ETAs. The catch is that proxies are stateless—they map one format to another, but they don’t validate or transform deeply. That means every schema change turns into a fire drill. Proxies win only when you control both ends of the contract and both teams agree to freeze changes for 90 days. Otherwise you’re patching YAML at 2 AM.

The real cost isn’t code—it’s operational friction. Each new partner means another proxy endpoint to maintain, another certificate to rotate, another monitoring dashboard. Most teams underestimate that overhead by a factor of three. One concrete sign you’ve outgrown a proxy: the same data transformation logic starts appearing in three different connector modules. That’s when the proxy stops being a shortcut and starts being a debt trap.

Not every mobility checklist earns its ink.

Not every mobility checklist earns its ink.

Middleware: handles many protocols, but adds latency and cost

Middleware platforms—think Mulesoft, Workato, or a self-hosted Kafka bus—promise protocol jack-of-all-trades. REST, gRPC, SOAP, flat files, even carrier pigeon (okay, almost). You pipe everything into the bus, it normalizes, and you write one set of target transforms. That feels clean. The first time you see a monitoring dashboard showing every partner’s message count in one pane, you’ll think you’ve won. What usually breaks first is latency. A message that takes 50 ms directly now takes 250 ms through middleware: serialization, persistence, routing, transform, re-serialization. For real-time dispatch that adds up. We measured a 340 ms median increase on a middleware stack for a European delivery network—that killed their “accept within 2 seconds” SLA for gig drivers. The second hidden cost is the vendor lock-in you’re trying to escape, just wearing a different hat. Once your entire integration topology runs through a middleware product, migration off it becomes a multi-quarter project. “You’ve just swapped platform vendor lock-in for middleware vendor lock-in.” — senior engineer, Berlin fleet ops, 2023.

— overheard at a postmortem, after the middleware provider raised per-message pricing by 40%

That said, middleware shines when you have 12+ partners all speaking different dialects and you can't afford to hand-code each adapter. The trade-off is a monthly bill that grows with message volume, plus a hard ceiling on how fast you can iterate. Middleware is a bridge, not a transformer—it connects, but it doesn’t fix mismatched business logic. If one partner sends “status: delivered” and another sends “event: dropoff_complete”, middleware can map the words, but it can't decide which one triggers a payment release. That logic still lives in your custom code, and middleware doesn’t make that code easier to test.

Custom adapter: full control, but you own the bugs forever

Writing a custom adapter in-house feels like the honest option. You control every byte, every retry policy, every error message. No third-party roadmap constraints. The first adapter I ever wrote ran for three years without a major rewrite. Felt great—until the partner deprecated their v1 API and my adapter, which was hardcoded to v1 response shapes, started throwing 500s on production. I owned that bug. Not the partner, not the proxy middleware. Me. Custom adapters give you total control over the integration logic and zero control over the partner’s evolution. The minute they change a field name from ETA_minutes to estimated_arrival_seconds, your adapter either breaks silently or you catch it in staging—if you have staging. Most teams skip this: they build the adapter, test once, and call it done. That hurts.

The real burden is ongoing. Every custom adapter needs its own CI/CD pipeline, its own monitoring, its own error-handling strategy. Multiply that by four fleet partners and you have a small integration team’s worth of maintenance. I have seen startups hire two engineers whose sole job is “keep the adapters alive.” That's expensive. A custom adapter makes sense only when the partner’s API is stable, the contract is bilateral (you can negotiate changes), and you have the engineering depth to own it long-term. Otherwise it’s a beautiful, bespoke trap—perfectly tailored to today’s API, completely wrong for next quarter’s.

After You Choose: The Implementation Path

Step 1: Map message flows and data contracts — before touching any code

Most teams skip this. They open two API docs side by side, nod, and start wiring endpoints. That works until a three-letter field name mismatch silently corrupts a driver-pay record three weeks into production. Here is the only reliable sequence: print every unique message type your current platform emits — trip start, trip end, geofence breach, payment confirmation, vehicle status ping. Now print the exact same event types your new partner expects. Put them on a wall. What happens when your old platform sends VehicleId but the new partner expects asset_ref? Or the old one emits a status every 30 seconds, but the new partner’s adapter rate-limits at one per minute? You map those mismatches before a single line of translation logic exists. One team I worked with skipped this step, hard-coded field positions from a sample payload, and lost 14 hours debugging a datetime format that flipped between UTC and local depending on which server processed the request. Map first. Code second.

Step 2: Build the translation layer — proxy, middleware, or custom adapter

Your choice from Section 4 now becomes actual code. If you picked an API proxy (like Kong or Tyk), your job is declarative: write transformation plugins that rewrite headers, remap endpoints, and reshape JSON bodies. The catch — proxies hate conversational state. A trip lifecycle involves five sequential calls; a proxy sees each one as a stateless HTTP hit. You will need a tiny companion service just to hold session context. Middleware (an ESB or lightweight event broker) handles state better but introduces latency. I have seen a middleware layer add 120 milliseconds per hop — unnoticeable for driver app pings, catastrophic for real-time geofence triggers. Custom adapters give you full control and zero bloat, but they become your new maintenance burden. Whichever path, build the translation layer inside a feature flag or a staging environment that mirrors production traffic. Don't point it at real vehicles yet.

“We spent two weeks building the perfect adapter. Then the new partner changed their auth header format. No one told us.”

— Integration lead at a 200-vehicle fleet operator

Step 3: Test with a parallel run — not a big bang cutover

Cutting over on a Sunday night is how operations directors develop ulcers. Instead, run both platforms simultaneously for at least one full business cycle — typically 72 hours for mobility operations. Your old system keeps handling live trips. Your new platform receives the same data through the translation layer, but the output goes to a shadow database or a test dashboard. Compare trip counts, payment amounts, vehicle status transitions. The parallel run catches the failures that unit tests miss: a field that defaults to null instead of 0, a timeout that works fine with 5 vehicles but blows at 200, a recurring authentication expiry that hits at 3 AM when no one is watching. Wrong order? Running a pilot with two vehicles while the rest stay on the old platform. That hides concurrency bugs. Run a minimum of 10 % of your fleet in parallel, ideally across different vehicle types and trip densities.

Step 4: Monitor for vendor API changes — because they will happen

Your new fleet partner will update their API. It's not malice — it's product velocity. What usually breaks first is the authentication endpoint (they rotate keys without a grace period) or a field they deprecate with a single email sent to your procurement contact who forwards it six weeks later. Set up a cron job or a serverless function that calls a health endpoint every hour and compares the response schema against a stored baseline. If the partner provides an OpenAPI spec, automate a diff against the version you integrated against. The tricky part is the silent deprecation — a field still returns data but the partner stops writing to it. Monitor field-level content, not just endpoint availability. One fleet operator lost 3 % of their driver bonus calculations because a bonus_eligible flag stopped flipping to true — the endpoint responded 200, the field existed, but it held stale data for 47 days before anyone noticed.

After the parallel run passes and your monitoring is in place? Cut over during a low-traffic window. Keep the old platform active as a read-only fallback for two more weeks. Remove it only when you're certain no downstream system — not even that forgotten spreadsheet in accounting — still queries it. That's the real implementation path, not a checklist. It's a process of proving, not deploying.

Risks of Choosing Wrong or Skipping Steps

Data corruption when field mappings are wrong

I watched a fleet ops team lose three days of trip data because someone mapped 'vehicle_id' to a VIN field that the new partner truncated at 14 characters. The platform accepted every row silently—no error, no warning. Just garbage in, garbage out. That sounds like a QA miss, but the real failure was architectural: they chose a custom adapter that bypassed the validation layer their old middleware had enforced for years. By the time they noticed the mismatch, the corrupted records had already propagated to billing, payroll, and customer invoices. One wrong field mapping—and suddenly you're cutting checks to drivers for phantom trips. The tricky part is that most mapping errors don't scream at you. They whisper. A decimal point in the wrong column. A time zone that defaults to UTC when your fleet runs on Eastern. You don't catch it until the seam blows out under real load.

Odd bit about services: the dull step fails first.

Odd bit about services: the dull step fails first.

SLA penalties from failed transactions

What usually breaks first is the transaction handshake—the moment your platform tries to confirm a dispatch and the new partner's API either doesn't respond or responds with a code your adapter wasn't built to handle. We fixed this once by adding a five-second timeout; the original custom connector had none. The result? A single slow endpoint locked up the entire dispatch queue for forty-seven minutes. The SLA penalty on that contract was $2,300 per hour of downtime. That hurts. Worse, the integration team had skipped the step where you test for partial failures—network blips, rate limits, authentication token expiry during peak hours. Most teams treat integration like a binary switch: it works or it doesn't. But modern mobility APIs fail in shades. A 429 (too many requests) is not the same as a 503 (service unavailable), yet your middleware or proxy might treat them identically. That's how you get throttled into a penalty.

Team burnout from maintaining a fragile custom connector

One logistics startup I know built a custom adapter in three weeks. It worked beautifully—for about two months. Then the fleet partner's API v3 went into deprecation, v4 introduced pagination changes, and nobody on the engineering team had documented the original connector's logic. The senior dev who wrote it had left. The juniors inherited a black box. Every minor version bump required two days of patchwork and a prayer. That's not sustainable—it's technical debt with an interest rate that compounds weekly. I have seen teams spend 60% of their sprint capacity just keeping one integration alive. Not improving it. Not adding features. Just patching the leaks. The catch is that skipping proper versioning and middleware abstraction feels efficient at first. You ship fast, the demo impresses leadership. But six months later, that connector is a haunted house—everyone's afraid to open the door.

'We thought we were saving time by writing our own adapter. Instead, we built a full-time job for someone we hadn't hired yet.'

— VP of Fleet Operations, after migrating off a deprecated API for the third time in eighteen months

Vendor lock-in worsens if you build on deprecated APIs

This is the irony: you choose a custom adapter to avoid platform dependency, but if you hardcode against an API version the vendor plans to sunset, you've actually deepened the trap. The deprecation timeline might be eighteen months—but your business cycle runs longer. By the time you need to switch partners again, that adapter is tied to a dead endpoint. No middleware to abstract the differences. No proxy to reroute. Just a rewrite from scratch. I have watched companies pay double the original integration cost because they assumed 'custom' meant 'future-proof.' It doesn't. Custom means you own the maintenance—and when the vendor changes the rules, you eat the migration cost alone. The smart play is not to avoid custom work entirely. It's to build a thin translation layer that isolates the partner-specific logic from your core platform. That way, when v4 replaces v3, you swap one module—not the whole engine. Teams that skip that isolation step rarely survive the second integration without a budget blowout.

Honestly—pick the integration path that lets you say "yes" to a new partner next quarter without reopening last quarter's code. Everything else is a gamble you don't need.

Mini-FAQ: Quick Answers to the Most Common Integration Questions

Will my platform vendor ever support this partner natively?

Usually, no—not unless that partner controls 30% of vehicles in your region. I have watched three separate vendors promise 'native integration' for two years and deliver nothing but a beta that broke authentication every other deploy. The honest calculus: platform vendors prioritize partners that move volume. If your new fleet partner is smaller or uses older telematics hardware, you’re looking at a roadmap item that keeps slipping. The trick is—stop waiting. Ask directly: 'Is there a paid tier or custom development contract?' If the answer is vague or defensive, assume never.

Can we use the partner’s own middleware instead of ours?

Yes—but you inherit their latency ceiling and their bugs. One team we fixed this by using the partner’s middleware for a three-month pilot; what broke wasn’t the data format but the retry logic. The partner’s middleware timed out on 8% of trips during peak hours, and our platform vendor blamed the partner, who blamed network routing. Nobody owned the fix. The catch is support ownership. If you run your own middleware, you control the escalation path. If you borrow theirs, you’re stuck in ticket queues that don’t share SLAs. That hurts. The trade-off: faster setup (60–90 days) vs. slower but debuggable setup (120–150 days).

What if we just fork the platform’s open-source SDK?

You can—and I have seen it work for exactly two teams. Most others regretted it within six months. The problem isn’t the code; it’s the update treadmill. The platform vendor pushes a breaking change to authentication headers every quarter. Your forked SDK? Silent. No alert, no patch. One fleet manager told me: 'We spent 80 hours a year merging upstream changes we didn't write and didn't fully test.' That’s time you could spend optimizing routes. Forking only makes sense if you plan to own that code like a product—dedicated engineer, CI/CD pipeline, regression suite. Otherwise, it’s technical debt wearing an open-source badge.

'The partner’s middleware failed silently for three days. We caught it from a cancellation spike, not an alert.'

— Fleet operations lead, North America regional carrier, 2024

The real question behind all three: who absorbs the failure? If you answer 'somebody else,' you haven’t built an integration—you’ve parked a grenade. Next step: audit your fallback plan. Does your TMS automatically failover to a manual dispatch queue? No? Then pick middleware, not a fork, and budget for the 5% overhead. Make that call before your Friday deployment window closes.

Recommendation Recap (No Hype)

For most fleets: start with a lightweight API proxy, then migrate to middleware if volumes grow

Nine times out of ten, the cheapest fix wins first. A lightweight API proxy — essentially a translation layer between your platform and the new fleet partner — costs a few developer-days and zero infrastructure changes. We fixed a client’s Paratransit integration in 72 hours this way. The catch? Proxies don't scale well past 2,000 daily trips. Once you hit that edge, latency creeps up and error handling becomes manual. That’s when you graduate to middleware. Not before. Most teams skip this step: they bolt on a proxy, forget about it, then wonder why GPS pings drop during peak hours. Your first question should be about volume trajectory, not vendor features.

Avoid custom adapters unless you have a dedicated integration team

I have seen three custom adapters in the field. Two were abandoned within six months. The third required a full-time engineer just to patch API version bumps. Custom adapters sound like freedom — they aren't. The problem is maintenance debt. When your fleet partner updates their endpoint schema at 2 AM (they will), you need someone awake and authorised to rewrite the adapter. That someone costs $1,200/day on contract. Honest advice: if you don't have a person whose only job is integration upkeep, don't open that door. A middleware vendor handles schema drift for you. The trade-off is monthly licensing fees. Decide what your team can actually sustain — not what looks agile in a slide deck.

“The adapter was beautiful. Until the partner changed their authentication flow and nobody noticed for three weeks.”

— Operations lead, regional shuttle fleet (2024 retrospective)

Always check your platform contract before writing any code

The most expensive mistake? Starting to code before reading Section 12 of your platform licence. One fleet operator spent $14k building a data bridge, only to discover their mobility platform prohibited third-party middleware connectors. The contract allowed only direct API calls — and only to pre-approved partners. That hurts. Your contract likely defines termination liabilities, data ownership, and integration timing windows. Some platforms charge per-adapter fees. Others ban reverse-engineered connectors outright. Don't assume fairness. Check the fine print with a lawyer who knows SaaS agreements. Then check it again. One rhetorical question worth asking: would you rather lose a week of legal review or six months of rework? — Your choice.