Category: Provider Network

REST Primer for F&I

I have worked with more than a few APIs, both “F” and “I” – pretty much all of the product APIs, plus the original open standard for credit applications – and I write about them occasionally.  See here, here, and here.  Mostly these have been SOAP, but REST is the standard for a growing community of digital retail players.

The first thing you need to know about REST is that it’s not synonymous with JSON.  If you get this wrong, you can produce a really bad API.  I saw one once, where the developers had simply converted all their old XML payloads to JSON.  You could tell because every call was a POST, even the rate requests.

Why is JavaScript more successful on the Web than Java? It certainly isn’t because of its technical quality as a language – Roy Fielding

The key to REST, as you can read in Roy Fielding’s dissertation, is making appropriate use of the Web’s native HTTP environment.  Practically, this means knowing a little bit about HTTP and how to use its commands, URLs, parameters, and headers.  For a concise guide, see The REST API Design Handbook by George Reese.

Philosophically, it means thinking about your API in terms of resources and not services.  This is completely different from SOAP APIs, which are called web services.  For example:

  • GET rates from a product provider, but
  • POST a new contract, and then
  • PUT status codes on the contract to void or remit

Fielding’s achievement was not only to define the REST style, but to derive the style from a specific set of requirements: stateless, client-server, code on demand, etc.  If you have ever wondered why JavaScript has become so popular, it is because JavaScript satisfies the code on demand requirement.

When you build a RESTful API, you should never break existing client code. Really, never. You don’t deprecate – George Reese

The URL in a REST call looks like a path, so you can do groovy things like:

  • GET /rates/{dealer} – gets all applicable rates for this dealer
  • GET /rates/{dealer}/{product} – gets only one product
  • GET /rates/{dealer}/{product}/GOLD – gets only the Gold coverage
  • GET /text/{dealer}/{product}/GOLD – gets the rich text description for Gold

For some live examples you can run right now, check out the NHTSA Vehicle API.  It has many handy methods like:

  • /vehicles/DecodeVin/{VIN}
  • /vehicles/DecodeVinExtended/{VIN}
  • /vehicles/GetAllMakes
  • /vehicles/GetEquipmentPlantCodes/{Year}

Note that you are making the request with straight HTTP and a query string, and you can have the response as JSON, CSV, or XML.  The NHTSA site will also show you the headers, the raw data, and formatted data.  Your tax dollars at work.  You should also check out the Edmunds API, VinSolutions, and Fortellis.

  • //api.edmunds.com/api/vehicle/v2/vins/{VIN}
  • //api.vinsolutions.com/leads/id/{LeadId}
  • //api.fortellis.io/vehicles/reference/v4/vehicle-specifications/vins/{VIN}

These are all examples you can emulate if you’re just getting started.  In particular, I recommend studying how they handle authentication and versioning.  Note how they’re organized around resources and, if you have an OO mindset, think of your objects first.  You will also want to look at platform tools like Swagger and MuleSoft.

Stop Using Combo Products

I have had a hand in designing a few menu systems over the years, and I have always disliked combo products.  You know what I mean: the VSC form, plus maintenance and PDR, on which Marketing has found an extra square inch to offer road hazard.

Menu people hate combo products because the whole point of menu selling is for the F&I Manager to combine products into packages, not the combinations defined by the provider’s form.  What if she wants to sell the factory’s VSC, but her own choice of ancillary products?

One cavil I sometimes hear is the definition of “a product,” but this is straightforward.  If it can be sold separately, like key protection, then it’s a product.  If it always rides on another contract, like car rental, then it’s not.

What I try to tell my menu clients (and reinforce with my API clients) is this:

  • The unit of work for presentation is the product
  • The unit of work for contracting is the form

The correct data structure thus has discrete products at the top level, then coverages with their rates, and form codes at the bottom.  Obviously, you can have different forms based on coverage, and you can have the same form for multiple products.  Then, in the contracting phase, you collect the products onto the forms as indicated.

Combo Products

Combo products persist because providers legitimately want to reduce the number of forms they manage.  The two-phase approach solves this.  Also, there are old-timers who design products based on the form.  I have even seen F&I shops where the completed contract form is used as a selling tool.

The package discount is the only serious challenge to the menu system.  A workaround here is to include a phantom product with no display and a negative price – although that may be as much work as developing an explicit feature.  Of course, if the manager chooses to discount a package other than one subsidized by a provider, then that discount is her responsibility.

I’ll close with an exception to the rule or, rather, a refinement.  Menu systems are compromised when we mistake forms for products.  On the other hand, there is a practical limit (six) to the number of products offered on a menu.  So, I can see the logic in a product that combines dent, coatings, windshield, and road hazard – especially PDR and windshield, if you think about how the services are delivered.

In this case, we are not merely combining products based on a form.  These products hang together in the same semantic class, appearance protection, and may indeed use separate forms.

Cancellation Refund for Service Contracts

The last time you turned in your car, did you remember to get the refund on your service contract?  Me neither, and I have been in this business a long time.  The only way I know to get the refund is to dig up the paper contract and phone the provider.  It’s like the “breakage model” behind rebates and gift cards.

The first time I tried, professionally, to account for the refund was at GMAC Insurance prior to the bankruptcy.  I was working on an interface to do rate quotes.  Our plan was to detect the existence of a prior GMPP contract, and then apply the refund as a discount to the new contract.

Imagine how many vehicles are traded or repossessed and never see the end of their VSC or GAP contracts.  Actually, I don’t have to imagine, because I have statistics from Rich Apicella, who runs Express Recoveries.  This is an ingenious business model, leveraging the provider relationships of F&I Express to automate VSC refunds for lenders.

In case of a repossession, the refund from a product contract will reduce the deficiency balance.  What was once found money in the recoveries department is now a compliance requirement.  It never hurts to review the CFPB Examination Manual.  This is from page 42:

Recoveries

This is a great business for F&I Express, because it’s countercyclical.  Their main business is originating product contracts and then, when times are bad, they can earn some money cancelling them.  It’s also handy as a leading economic indicator.

Disclosure:  Intersection Technologies is a client and, although I am not working with Express Recoveries, Rich is just down the hall.  

Farewell to PEN

Clients are often surprised when I say, “my work here is finished.”  The consultant’s handbook says you should hang around until they’re sick and tired of you.  I feel it is better, when retained for a specific task – like a startup – to do the job in good style and then move on.

So it is with Provider Exchange Network.  The business model is established, the software is up and patented, and the staff are fluent in their new roles.  It has been my pleasure to work with the talented people at PEN, and I wish them all the best.