Build a business card scanner that writes to your CRM

A business card is a badly designed data entry form. The phone number has spaces in it, or dots, or a leading zero and no country code. The email is set in a font where a lowercase L and a capital I are the same glyph. Half of them now carry a QR code holding all of this in machine readable form, and almost nobody reads it.

Getting a card into a CRM is one extraction job and one POST. Most of the cleanup happens before the result reaches you.

This closes a short series on consumer apps that are mostly one API call: a meal photo calorie tracker, a receipt scanner and bill splitter, and a barcode pantry tracker.

The pipeline

1. One job. Front and back of the card in a single request, typed contact fields back.
2. Your CRM. One authenticated POST to whichever API you already use.

Two photos, one job

sources is an array and everything in it is read as one document set, so the back of the card is not a second job. Send both sides and the fields are filled from whichever side carries them.

{
  "sources": [
    { "type": "image", "data": "data:image/jpeg;base64,/9j/4AAQ...front" },
    { "type": "image", "data": "data:image/jpeg;base64,/9j/4AAQ...back" }
  ],
  "engine": "vera-1.0-high",
  "schema": {
    "type": "object",
    "properties": {
      "full_name": { "type": "string" },
      "job_title": { "type": "string" },
      "company":   { "type": "string" },
      "email":     { "type": "string", "format": "email" },
      "phone":     { "type": "string", "format": "phone", "description": "Main or landline number." },
      "mobile":    { "type": "string", "format": "phone" },
      "website":   { "type": "string", "format": "uri" },
      "address":   { "type": "string", "description": "Street address as printed, one line." },
      "country":   { "type": "string", "format": "country" },
      "language":  { "type": "string", "format": "language", "description": "Language the card is printed in." },
      "card_qr":   { "type": "string", "format": "qrcode" }
    },
    "required": ["full_name"]
  }
}

{
  "full_name": "Ana Silva",
  "job_title": "Head of Partnerships",
  "company": "Cordoval",
  "email": "ana.silva@cordoval.pt",
  "phone": "+351213456789",
  "mobile": "+351912345678",
  "website": "https://cordoval.pt",
  "address": "Rua Garrett 12, 1200-203 Lisboa",
  "country": "PT",
  "language": "pt",
  "card_qr": "BEGIN:VCARD VERSION:3.0 N:Silva,Ana TEL:+351912345678 END:VCARD"
}

Notice what you did not have to write.

The phone is E.164. A card printed in Lisbon says 21 345 67 89 and means +351213456789. Completing that needs the country, which is not in the number, so the extraction reads it off the card itself: the address, the language, the domain suffix. That is a perception task, which is the model's job. The formatting that follows is mechanical, and it runs in code.

The country is ISO 3166-1 alpha-2. PT, not "Portugal" and not "PRT".

The email is canonical lowercase, so Ana.Silva@Cordoval.PT and ana.silva@cordoval.pt do not become two contacts.

The QR is decoded, not read. Where a card carries a vCard or a LinkedIn URL in a QR code, a real decoder resolves it before extraction and the payload lands in card_qr byte for byte. If there is no code, the field is null rather than a plausible looking URL.

One rule sits behind all of those, and it decides how far you can trust the output: resolve or leave alone, never fabricate. A phone number that cannot be completed to E.164 comes back exactly as printed. A country word with no mapping stays the word. Anything that arrives raw is visible in your data and can be routed to a human, while a quietly guessed value cannot.

The same holds for absence. A card with no address gives you null, which is why required in that schema has exactly one entry. Everything you mark required is pressure to produce a value, so reserve it for what is genuinely always there.

The POST

Whatever CRM you use, this is the boring half. HubSpot as an example:

async function createContact(card: ExtractedCard) {
  const response = await fetch(
    "https://api.hubapi.com/crm/v3/objects/contacts",
    {
      method: "POST",
      headers: {
        Authorization: `Bearer ${process.env.HUBSPOT_TOKEN}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({
        properties: {
          firstname: card.full_name.split(" ")[0],
          lastname: card.full_name.split(" ").slice(1).join(" "),
          email: card.email,
          phone: card.mobile ?? card.phone,
          company: card.company,
          jobtitle: card.job_title,
          website: card.website,
          country: card.country,
        },
      }),
    },
  )
  if (!response.ok) throw new Error(`hubspot ${response.status}`)
  return response.json()
}

That name split is deliberately naive, and it is wrong for compound surnames, for patronymics and for most of the world. Splitting a name is a policy decision rather than a parsing one, so either ask the schema for given_name and family_name separately, or show the split on a confirmation screen and let the person fix it.

What you still have to build

Deduplication. Everyone at a conference hands out the same card twice. Match on canonical email first, then on phone, and merge rather than insert. This is the feature that decides whether the CRM stays usable.

A confirmation screen. One card, one glance, editable fields. Nobody trusts silent writes into their own CRM, and nobody should.

The CRM auth. OAuth, token refresh, per user connections, rate limits on their side. This will take longer than the extraction did.

The empty paths. Job failed, an unreadable photo, a card that is genuinely a logo and a first name. A failed job refunds its hold in full, so the retry costs you nothing, but the user still needs to be told something.

Cost and shape

POST /v1/jobs/create returns immediately with an id and status: "pending", and the result arrives on your webhook_url or through GET /v1/jobs/:jobId/get. Two images in sources is still one job.

The number we publish is measured: $5.63 per 1,000 pages on vera-1.0-high across the full 1,651 page OmniDocBench run. That is whole page transcription, the heaviest output there is. A business card against ten fields is nowhere near it, because output size is what drives the bill.

Start here

The quickstart runs the first card in a few minutes, schemas and formats is the full format table, and verified values covers what gets checked rather than merely formatted.