BizKitHub Developer Documentation

Parameters

1 query · JSON body

Query parameters

· 1

apiKeystringRequired

Your BizKitHub API key (passed as GET parameter).

Key format: A 32-character string matching: ^(PROD|DEV_|ROOT)[A-Za-z0-9]{28}$
Prefixes: PROD (production key), DEV_ (individual developer), ROOT (system key with no limits). Learn more

ExamplePRODPGrFxpGEtrOZfuWhnoJohUYBXuOE

Request body

application/json

Paying customer (payer). This customer pays the order and is used as the primary billing entity. If the specified customer account does not exist, the system will automatically create a new customer and link it to the order.

emailstringRequired

Contact email address.

The system validates the input as a standard email address and automatically applies normalization and canonicalization.

All API responses return the normalized form, and each email address is unique per organisation within the system.

Phone-only contacts: Since 2026-06-10 a contact may exist without an e-mail when it was registered only by phone (e.g. imports of phone-only records). Responses that expose such contacts use API_EMAIL_NULLABLE instead, where this field can be null. Endpoints that accept e-mail as input still require a valid value here — phone-only creation goes through admin-only import / BFF flows.

Examplejan@barasek.com

namestringOptional

ExampleJan Barášek

firstNamestringOptional

ExampleJan

lastNamestringOptional

ExampleBarášek

phonestringOptional

Contact phone number in international (national) format.

Preferred format: +<country_code> <local_number>

Leading plus sign (+) is required
Followed by the country calling code (e.g. 420)
One space after the country code
Full local number without spaces

Example: +420 777123456
This format ensures unambiguous storage, validation, and compatibility with SMS, calling, and third-party integrations (e.g. Twilio, WhatsApp, CRM systems).

Example+420 777123456

companyNamestringOptional

ExampleBizKitHub

companyRegistrationNumberstringOptional

Example05103118

taxIdentificationNumberstringOptional

ExampleCZ9609040727

streetAddressstringOptional

ExampleR. Novotného 1505

citystringOptional

ExampleKladno

cityPartstringOptional

ExampleKročehlavy

stateRegionstringOptional

ExampleStředočeský kraj

postalCodestringOptional

Example272 01

countrystringOptional

ExamplesCZČeská republikaCzechiaCzech

newsletterbooleanOptional

Default: false

primaryLocalestringOptional

Examplecs

groupsstring[]Optional

customerRealIpstringOptional

Accepted formats:

IPv4 dot-decimal, e.g. 1.1.1.1 (4 octets, 0–255, no leading zeros).
IPv6 as defined by RFC 4291 — full 2001:0db8:0000:0000:0000:0000:0000:0001, zero-compressed 2001:db8::1, IPv4-mapped ::ffff:1.2.3.4, or scoped literals. Both upper- and lower-case hex are accepted.

Server-side canonicalization (ipNormalize in core/src/lib/network/ipNormalize.ts):

Valid IPv4 is passed through verbatim.
Valid IPv6 is lowercased (RFC 5952 §4.3).
IPv4-mapped IPv6 ::ffff:X.X.X.X is unwrapped to plain IPv4 (RFC 4291 §2.5.5.2) so 1.2.3.4 and ::ffff:1.2.3.4 share one brj__geo_ip row.
Loopback aliases (::1, 0.0.0.0, localhost, empty string) collapse to 127.0.0.1.
Junk values that fail both IPv4 and IPv6 validation are silently rejected and replaced with 127.0.0.1 (loopback).

On the wire: every response returns the canonicalized form — clients can safely rely on lowercase IPv6 and the plain-IPv4 unwrap when de-duping or joining. Server-originated writers (activity log, session log, ban list) resolve the visitor IP via resolveClientIp / resolveClientIpOrNull — always native IPv6 on Vercel Edge (there is no auto-mapping to ::ffff:X.X.X.X).

Enrichment: the system resolves reverse DNS, geolocation, ASN, mobile/proxy/hosting/Tor flags via our VikiTron GEO/IP resolver for both address families. Learn more

Examples1.1.1.12001:4860:4860::8888

referralIdstringOptional

cuRefNo = customer reference number.

Length: 16–16

Example1cGIHvFoQDGLAbcA

Response schema

1 status code documented

200Success

success"true"Required

Response example