Digital Business Card API: A Developer's Guide to Custom Integrations

For most users, digital business card platforms are configure-and-done products. But for developers and technical teams, the API layer is where DBC platforms transform from off-the-shelf software into building blocks for custom workflows: automated provisioning, branded apps, event-driven automation, and data warehouse integrations that native connectors can't support.

This guide covers digital business card API integration from a developer's perspective: which platforms expose APIs, authentication patterns, core endpoint categories, common use cases, webhook architecture, and the code patterns that make integrations maintainable at scale.

Before You Build: Do You Actually Need an API?

Most organizations that reach for a DBC API don't need one yet. Native integrations — HubSpot connector, Zapier bridge, CRM sync — cover the majority of real-world requirements without a line of code.

APIs make sense when:

• You need to auto-provision cards for new employees from an HR system without manual admin
• You're building a branded mobile app using the DBC platform as its backend
• You want to pipe engagement data to a data warehouse (Snowflake, BigQuery) for BI analysis
• You need business logic beyond native integrations — multi-property routing, custom scoring, proprietary field mappings
• You're building multi-tenant SaaS where digital cards are an embedded feature

If none of these apply — if you need HubSpot sync and lead capture — start with the native connector. The API is for when native connectors hit their ceiling.

And if you're a solo professional or small team that doesn't need any of this: BizBuzz Cards delivers a complete out-of-the-box experience — built-in contact CRM, AI semantic search across your saved network, mini-site templates, QR code sharing — without any integration code. Save the API build for when you genuinely outgrow the native product.

Platforms with Public APIs

Major DBC platforms with documented, developer-accessible REST APIs (as of mid-2026; verify current API availability with each vendor):

HiHello — Comprehensive REST API with endpoints for user management, card operations, analytics, and webhook subscriptions. Among the best-documented APIs in the DBC category. Available on Business and Enterprise tiers.

Mobilo — REST API focused on enterprise team management and CRM integration. Strong for employee lifecycle automation. Available on Pro and Enterprise plans.

Popl — API access available for enterprise customers, focused on lead capture and CRM routing.

Uniqode — QR-focused platform with a well-documented API for QR code lifecycle management, analytics export, and bulk operations at enterprise scale.

API documentation quality varies significantly across platforms. Before committing to a platform for an API integration project, read the actual reference docs — not the marketing page claiming "developer-friendly API."

Authentication

Most DBC platforms use API key authentication for server-to-server operations:

GET /v1/cards
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

Generate your API key in the platform dashboard. Treat it as a high-value secret:
- Store in environment variables or a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler)
- Never commit to source control — add .env to .gitignore before the first commit
- Rotate on a schedule (90-day rotation is a reasonable baseline)
- Request minimum required scope (read-only where write access isn't needed)

For operations that act on behalf of individual users (not just the admin account), platforms typically use OAuth 2.0. The user completes a standard authorization flow; your app receives a scoped access token with configurable permissions.

Core Endpoint Categories

Most DBC platform APIs expose variations of these endpoint groups:

User and Profile Management

GET    /v1/users              # List users in your account
POST   /v1/users              # Create a new user
GET    /v1/users/{id}         # Fetch user profile details
PATCH  /v1/users/{id}         # Update profile fields
DELETE /v1/users/{id}         # Deactivate or remove user

Card Operations

GET    /v1/cards              # List cards
POST   /v1/cards              # Create a new card
GET    /v1/cards/{id}         # Fetch card details
PATCH  /v1/cards/{id}         # Update card content
DELETE /v1/cards/{id}         # Delete card
POST   /v1/cards/{id}/publish # Publish changes

Analytics

GET /v1/analytics/scans?start=2026-01-01&end=2026-06-30
GET /v1/analytics/conversions
GET /v1/analytics/users/{id}/engagement

Wallet Pass Generation

POST /v1/wallet/apple/passes              # Generate Apple Wallet pass
POST /v1/wallet/google/passes             # Generate Google Wallet pass
POST /v1/wallet/apple/passes/{id}/push    # Push update to installed passes
POST /v1/wallet/google/passes/{id}/push   # Push update via Google Wallet API

Webhooks

POST   /v1/webhooks        # Register webhook
GET    /v1/webhooks        # List registered webhooks
DELETE /v1/webhooks/{id}   # Remove webhook

Exact endpoint names and shapes vary by platform — always check the platform's own API reference for authoritative documentation.

Use Case 1: Automated Employee Onboarding

The most common enterprise use case. Flow:

1. HR system (Workday, BambooHR) marks employee as active.
2. HR system POSTs a webhook to your middleware.
3. Middleware calls the DBC platform API:
   • POST /users — creates the account with employee data
   • POST /cards — creates a card linked to that user
   • POST /wallet/apple/passes — generates Apple Wallet pass
   • POST /wallet/google/passes — generates Google Wallet pass via Google Wallet API
4. Welcome email sent with card setup URL and wallet links.

Result: new hires have functional digital business cards on Day 1 with zero manual setup.

import requests
import os

API_KEY = os.environ['DBC_API_KEY']
BASE = 'https://api.yourplatform.com/v1'
headers = {
    'Authorization': f'Bearer {API_KEY}',
    'Content-Type': 'application/json'
}

def provision_employee(name, email, title):
    # Create user
    user_resp = requests.post(f'{BASE}/users', headers=headers,
        json={'name': name, 'email': email, 'title': title})
    user_resp.raise_for_status()
    user_id = user_resp.json()['id']

    # Create card
    card_resp = requests.post(f'{BASE}/cards', headers=headers,
        json={'user_id': user_id, 'template': 'corporate_standard'})
    card_resp.raise_for_status()

    # Generate wallet passes
    apple = requests.post(f'{BASE}/wallet/apple/passes', headers=headers,
        json={'user_id': user_id}).json()
    google = requests.post(f'{BASE}/wallet/google/passes', headers=headers,
        json={'user_id': user_id}).json()

    return {
        'user_id': user_id,
        'apple_pass_url': apple['download_url'],
        'google_pass_url': google['save_url']
    }

Use Case 2b: Automated Employee Offboarding

The onboarding automation has a necessary mirror: when an employee leaves, their card and wallet passes should deactivate automatically — the same day, not whenever someone remembers.

Offboarding flow:

1. HR system marks employee as terminated.
2. HR webhook fires to middleware.
3. Middleware calls DBC platform API:
   • DELETE /users/{id} or PATCH /users/{id} with {status: "inactive"} — deactivates the account
   • Platform pushes pass invalidation to Apple Wallet (pass displays "voided") via APNs
   • Google Wallet pass marked expired via Google Wallet API
4. Any leads or contacts owned by the departing employee are reassigned via CRM API.
5. Audit log entry recorded.

Without automation, a departed employee's card can continue functioning — directing any taps to contact information the company no longer controls — until someone manually notices and deactivates it. That's a brand risk for high-turnover teams or large enterprises.

The same middleware that handles onboarding can handle offboarding by listening for the "terminated" status event from the HR system and calling the appropriate deactivation endpoints. The code structure is nearly identical to provisioning, but in reverse.

Use Case 2: Event-Driven CRM Workflows via Webhooks

Subscribe to platform webhooks to trigger custom actions on card interactions:

Typical webhook events:
- card.viewed — profile page loaded
- form.submitted — lead capture form completed
- pass.added — Apple Wallet or Google Wallet save
- link.clicked — specific profile link clicked
- booking.initiated — calendar link tapped

Registering a webhook:

POST /v1/webhooks
{
  "events": ["form.submitted", "pass.added"],
  "url": "https://api.yourcompany.com/webhooks/dbc",
  "secret": "your_signing_secret"
}

Verifying webhook signatures (always do this):

import hmac
import hashlib

def verify_signature(payload_bytes, received_sig, secret):
    expected = hmac.new(
        secret.encode(), payload_bytes, hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(f'sha256={expected}', received_sig)

@app.route('/webhooks/dbc', methods=['POST'])
def handle_dbc_webhook():
    sig = request.headers.get('X-Webhook-Signature')
    if not verify_signature(request.data, sig, WEBHOOK_SECRET):
        return '', 401

    event = request.json
    if event['type'] == 'form.submitted':
        create_crm_contact(event['data'])
    elif event['type'] == 'pass.added':
        boost_lead_score(event['data']['user_id'])

    return '', 200

Never process webhook payloads without signature verification — anyone can POST to your endpoint without it.

Use Case 3: Data Warehouse Integration

For analytics-heavy organizations, pipe DBC engagement data to a data warehouse:

1. Scheduled job (daily or hourly) pulls analytics from the platform API
2. Transforms and loads into Snowflake or BigQuery
3. BI tools (Looker, Tableau, Metabase) build dashboards combining DBC engagement data with CRM pipeline and revenue data

This produces unified attribution: which networking activity produced which revenue, traced from card tap through CRM opportunity to closed deal — in a single BI view.

Rate Limits and Error Handling

Most platforms enforce rate limits to protect API stability (limits vary; check your platform's docs — commonly in the 100–500 requests/minute range per API key).

Handle limits and errors defensively from day one:

import time
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

def create_api_session():
    session = requests.Session()
    retry = Retry(
        total=3,
        backoff_factor=1,
        status_forcelist=[429, 500, 502, 503]
    )
    session.mount('https://', HTTPAdapter(max_retries=retry))
    return session

Standard HTTP status codes apply: 200/201 for success, 400 for validation errors, 401 for auth failures, 403 for permission errors, 404 for missing resources, 429 for rate limiting, 5xx for server errors. Always handle 429 with the Retry-After header value, not a fixed sleep.

Webhook Security Checklist

Before deploying any webhook endpoint to production:

• ✅ Signature verification implemented and tested with incorrect signatures
• ✅ Request body read as raw bytes before parsing (signature is over raw bytes, not parsed JSON)
• ✅ WEBHOOK_SECRET stored in environment variable, not source code
• ✅ Endpoint returns 200 quickly (process asynchronously for slow operations)
• ✅ Idempotency handled — replay the same event, get the same outcome

Versioning and Long-Term Maintenance

APIs evolve. Pin your integration to a specific version:

https://api.yourplatform.com/v1/users  # Pinned to v1

Subscribe to the platform's developer changelog or newsletter. Schedule version migrations before deprecation deadlines, not after. An API integration that worked at launch can silently break when a platform removes a field from a response body — only automated integration tests catch this.

Pricing Considerations

API access is typically included in mid-tier and enterprise plans, not priced separately. (Verify before purchase — plans change frequently.)

• HiHello: API available on Business tier (~$5–6/user/month annual, per HiHello's pricing page) and Enterprise
• Mobilo: API on Pro and Enterprise tiers (~$4/user/month annual, per Mobilo's pricing)
• Popl: API for enterprise customers

For most use cases, the API access is bundled within the plan cost already appropriate for the team's size.

Common Integration Mistakes

Hardcoding API keys — use environment variables or a secrets manager; never source control.

No webhook signature verification — a critical security gap; non-negotiable to fix before production.

Ignoring rate limits — implement exponential backoff from the first commit.

No error handling for 4xx/5xx — network calls fail; design for retries from day one.

Pinning to the latest version path — when the platform releases v2, your v1 calls should continue working on the pinned version. Use versioned URL paths explicitly.

Skipping sandbox testing — most platforms provide sandbox environments; use them before touching production data.

Bottom Line

DBC platform APIs follow standard patterns: REST, API key or OAuth authentication, webhook event streams, and versioned URLs. The specific endpoint names vary by platform, but the architecture is consistent enough that developers familiar with any REST API can get productive quickly.

Start with native connectors; reach for the API when native connectors can't cover your requirements. Design for retries, signature verification, and version stability from the first commit, and the integration will run reliably for years.

Sources

• Google Wallet API documentation — Google for Developers
• HiHello pricing — HiHello
• Mobilo plans — Capterra
• Popl enterprise features — Popl