Tag: API

My JSON Resume

No, this is not my resume for JSON skills, although you might want to check out my REST Primer for F&I.

This post came out of a running dialogue, on Twitter and LinkedIn, about how to format your resume. The observation, not original with me, is that it’s silly to worry about formatting when your resume will be parsed into an Applicant Tracking System (ATS) anyway.

There should be a global resume template, and you should be able to transmit it as JSON directly into the ATS.

There is general agreement that job seekers should be able to write their resume once, and then submit it effortlessly to job listings. Yes, I know, people may shotgun their resume indiscriminately, but that’s what the ATS is for. Relying on the “friction” of resume uploads is not a great way to filter applicants.

In this post, we’ll look at the HR Open standard, JSON Resume, and LinkedIn Easy Apply.

HR Open Standards Organization

The HR Open Standards Organization is an ambitious plan to put everything HR on an API, including screening, benefits, and payroll. I signed up and acquired release 4.4 of the schema. This release includes several features of interest to recruiters, such as:

  • The Learning Employment Record (LER-RS).
  • Focus on skills and competencies, versus job titles and duties.
  • Digital verification of credentials and achievements.

The resume-like elements are in the Person Profile type, which resides in the Candidate type.

Candidate may include data that is not typically included on a Resume, such as remuneration requirements and position preferences.

You can tell that much of the work was done in XML before adding JSON in release 4.0. The schema is intended for integration among commercial HR systems, and that’s who the organizers are. So, no surprise they’re SOAP oriented.

The schema has roughly 350 high-level elements, and nests down 28 levels. My automotive readers will note the analogy with STAR. When I was at AutoNation, we developed the first XML standard for credit applications (CAF). We had the top auto lenders onboard, including Chase Auto Finance.

Chase spun off Dealertrack, which launched on CAF and later went to STAR. STAR is deep and detailed. CAF, while thorough, was quick and dirty by comparison. Similarly, where HR Open is the official industry standard, JSON Resume is the scrappy startup.

JSON Resume Ecosystem

You can tell JSON Resume is built by developers, for developers. In addition to the JSON schema, the ecosystem includes:

  • Command Line Interface (CLI)
  • Export utilities
  • Chrome extension
  • Latex rendering
  • Multiple “theme” formatters
  • Hosted registry
  • YAML, TXT, and QR Codes

This is so comprehensive that I had to laugh. My JSON resume is here. Now, I can generate it as a PDF in one of the thousand available themes. I used the included editor to develop this resume, which it automatically publishes as a Gist on my GitHub.

JSON Resume also hosts a registry. That is, it automatically generates a web page based on the JSON file. I didn’t have to lift a finger. Here is my resume online. Other great things are in prospect, like vectorizing resumes and using cosine similarity to match them with job listings.

The tools are user-friendly enough, and I’d love to see more people in the registry, but right now it seems to be mostly just developers.

LinkedIn Easy Apply

LinkedIn Easy Apply is basically a preprocessor for the client’s ATS. It does the work of parsing a PDF resume and merging it with the already-structured data in your LinkedIn profile. Then, it uses proprietary APIs to talk to Workday, Greenhouse, et al. If you’ve used it, you know the parsing is often bad.

The easiest enhancement would be to accept JSON as input, validating against the JSON Resume schema. LinkedIn could even allow users to edit their online profiles as JSON, basically cribbing the JSON Resume editor. They already have your profile in an object model, internally.

Input could also include the standard questions about race, nationality, disability, and work eligibility. While these are technically not part of the resume, they could be included as metadata in the same file. They’re already in the HR Open standard.

Agent Support for Menu Selling

As a software guy, I am always surprised to find F&I trainers doing generic menu training without attention to the specific menu system used in the dealership. There is some generic advice, which I covered in Best Practices for Menu Selling, but then your client’s next question is going to be: “How do I do that on Darwin?” Or Maxim. Or Tekion.

Controlling the menu means you control what products are on it, and how they’re presented.

Familiarity with the given menu system is even more important when you represent a provider or agent. Now, you’re not only training how to sell product, but to sell your product. As I told my boss at Safe-Guard, “you can put a gun to the guy’s head but if your product isn’t on the menu, he’s not selling it.”

And we have seen exactly this. “We don’t sell your coverage because it’s a lease deal.” Because it’s preowned. Because it’s highline. By “we,” I mean Safe-Guard’s ace menu trainer, Michele McMinn, and the menu support team we put together. Double your penetration with this one weird trick…

The easiest way to do this is to pay for the dealer’s menu system. Then, your trainers only have to be experts in one system, and you have a hotline to their tech support department.

Controlling the menu means you control what products are on it, and how they’re presented. If your dealer base is too diverse for that, then you will have to develop F&I trainers who are expert in all of them.

Setting Up the Menu Support Team

You also have to make sure your products are compatible with certain standards used by PEN and the menu-system community. If this is news to you, you’re not alone. Even in the year 2025, I still find providers and agents who think their product is a piece of paper.

Just because the art department added a checkbox for “Rebate” or “Sagittarius,” doesn’t mean that checkbox is going anywhere unless you know a little something about the PEN interface standards. Here’s what a good menu support team looks like:

  • Trainers who are rated on more than one menu system, in addition to generic F&I training.
  • Dedicated support, so the trainers can reach someone while they’re in the dealership. This is key. The menu support desk also looks for recurring issues and develops a knowledge base.
  • Tech people who can run tools like Postman and XML Spy and, ideally, get involved with coding on your menu-system API (the interface that PEN uses).

At Safe-Guard, I went so far as to hire a Product Manager to own the API and to liaise with PEN and the menu-system community.

Designing menu-friendly products starts at the very beginning, when the coverage product manager meets with my product manager. Let’s say you want to offer Tire, Key, and Dent on the same form. Do you want all seven possible combinations? What about the “cosmetic” upcharge?

It’s not enough to have the right boxes on the form. You need to think about how the product will flow through PEN, and how it will look on Darwin. And Maxim. And Tekion.

It’s not enough to have the right boxes on the form. You need to think about how it will look on Darwin.

You can see how this is a team effort. If your product is making the menu choke, support needs to run that issue back to the programmers. If your trainer isn’t rated on that menu, she shouldn’t be in that store.

By the way, you should keep track of which DMS, which menu, and which sales process is used in each store. Keep track of those, along with the training sessions, after-action reports, and your (rapidly improving) penetration scores.

When Michele and I started playing this game at a high level, we discovered we were competing with JM&A. That was it. Everyone else was unarmed.

Provider Support for Digital Retail

A couple of press releases caught my attention last week.  The first one was APCO Acquires Strategic Diversified.  So, what’s new about that?  F&I providers have been acquiring agencies ongoingly, in parallel with consolidation among car dealers.  What caught my attention was this, from CEO Rob Volatile, “the additional resources APCO will provide, particularly in digital retailing, will help our dealers thrive in the changing times ahead.”

“The additional resources APCO will provide, particularly in digital retailing, will help our dealers thrive in the changing times ahead.” 

By now, everyone understands that small dealer groups don’t have the resources to compete effectively in digital retail.  This includes even the mighty Larry Miller group.  As CEO Steve Starks said of the Asbury sale, “we had grown the business about as large as we could without having an over-the-top digital retail strategy.”

Product providers, agents, and finance sources must have value-enhancing digital skills – which brings me to the second press release, Assurant Unveils Omnichannel Sales Optimization Suite.  This, again, is not new.  All providers have some kind of digital outreach program.  I served on the digital retail team at Safe-Guard.  In addition to my main job of growing the API business, we provided research, content, and coaching to our clients – not unlike Assurant’s offering.

What caught my attention was the high-profile announcement including, as McKinsey recommends, senior leadership for digital transformation.  This same SVP, Martin Jenns, is quoted here in an Automotive News roundup.

How F&I Providers Can Support Digital Retail

So, what can a product provider do to support “omnichannel sales optimization?”  I asked some of my pals in digital retail.  Definitely the training and API capabilities, plus digital content.  Cited as leaders were Assurant and JM&A.

“Providers should pay specific attention to how their products will present on a digital retail platform.”

The best advice came from AutoFi’s Matt Orlando, who told me, “providers should pay specific attention to how their products will present on a digital retail platform.”  That is, instead of the (completely different) experience on a portal or a menu.

For example, a service contract may have more than one hundred combinations of coverage, term, deductible, and other options.  That doesn’t work for an online consumer.  Providers should apply some analytics, Matt said, and transmit only the most-likely rates.

Short, snappy videos are the preferred digital content.  Digital retail vendors will generally set these up on request although, in my experience, it’s better if the provider can transmit the latest content via API and in various formats.  See my REST Primer for F&I.

  • White papers – Do some research, find success stories, and write informative long-form articles. Also, promotional content like newsletters, roadmaps, infographics, and this eBook.
  • Coaching – For your non-reading clients, be prepared with live-delivery content – and people.
  • API capabilities – Invest in advanced API capabilities like real-time analytics and digital content. Push the envelope of what digital retail can present.
  • Digital content – Produce digital content as video, image, and rich text (not HTML) for each level of your product hierarchy.
  • Resource center – Make all of this available to your clients using a purpose-built microsite – and people.

I remember back when the old-timers used to say that protection products “are not bought, they’re sold.”  Well, digital F&I results now exceed those in-store, with some platforms reliably above 2.0 product index.

In the midst of an inventory shortage, dealers must sell more product on fewer vehicles – and product providers must be part of the solution.

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.