Contact data validation

Carriyo performs static validation on phone numbers and email addresses at booking time, but the most reliable place to catch bad contact data is upstream, at order capture, in your own integration. Bad numbers and undeliverable email addresses cause two problems: failed customer notifications, and failed deliveries when the carrier can't reach the recipient.

This page covers the libraries we recommend and the format conventions to follow.

Phone numbers

The right approach is static validation, verifying that the number is correctly formatted, valid for the specified country, and structurally sound. Static validation does not check whether the number is reachable or active; for that you'd need a separate SMS-OTP or call-back flow.

Libphonenumber

Libphonenumber is the industry standard. Originally developed by Google for Android, now widely used across global platforms. It validates numbers for all countries, detects format / length / type (mobile vs landline vs toll-free), and formats numbers as E.164, national, or international format.

What it does not do: confirm a number is active or reachable. It is purely syntactic and structural.

Libraries by platform

Platform	Library
JavaScript	Libphonenumber-js, lightweight, ideal for web
Java	Libphonenumber, official Java port
Python	Phonenumbers, full-featured Python port
PHP	Libphonenumber-for-php
Front-end UI	Intl-tel-input, input component with country picker

JavaScript example

import { parsePhoneNumberFromString } from 'libphonenumber-js';

const input = '+14155550132';
const phoneNumber = parsePhoneNumberFromString(input);

if (phoneNumber && phoneNumber.isValid()) {
  console.log('Valid:', phoneNumber.formatInternational());
} else {
  console.log('Invalid phone number');
}

Store and submit numbers in E.164 format (+CCNNNNNNNN) for consistency across systems and for unambiguous delivery to international SMS gateways.

Email addresses

Static validation here means checking that the address is syntactically correct per RFC 5322. Like phone validation, this confirms the address could be valid. It does not confirm deliverability.

For high-stakes flows (customer registration, order confirmation), go further with a verification email containing a confirmation link. That's the only way to confirm the address is active and owned by the customer.

Avoid custom regex for email validation, the RFC is permissive and most homegrown patterns produce false positives or false negatives. Use a maintained library.

Libraries by platform

Platform	Library
JavaScript	Validator.js
Python	Python-email-validator
Java	Apache commons validator

Best practices

• Validate on both sides. Client-side for fast feedback during order capture; server-side as the authoritative gate before any data is persisted or sent to Carriyo.
• Store phones in E.164. Stripping country codes or reformatting at submission time is a common source of subtle bugs.
• Don't roll your own regex. Both phone and email standards have edge cases that homegrown patterns miss.
• For email, layer in verification. Static format validation is the floor; verification emails are the ceiling for any flow where a wrong address has real downstream cost.