Input Sanitization

To guarantee successful synchronization and prevent silent truncation by QuickBooks Desktop, the nXus API automatically sanitizes all text inputs to a strict printable ASCII format.

How It Works

When our system detects non-standard Unicode characters (such as smart quotes, auto-formatted fractions, or typographic ligatures), it safely converts them into their standard text equivalents. For example:

• Fractions like ½ become 1/2
• Special characters like © become (C)
• Accents like é are normalized to e

⚠️ Important Note on Field Lengths: Because a single character (like ™) may be expanded into multiple characters ((TM)), your total string length may increase during sanitization. Please ensure your inputs leave a small buffer for these expansions to avoid hitting QuickBooks’ strict maximum character limits (e.g., 31 characters for Item Names).

Character Conversion Reference

The following table outlines how the nXus API handles complex characters before passing them to the QuickBooks engine:

Character Type	Example Input	Sanitized Output	Reason
Accents / Diacritics	Curaçao, café	Curacao, cafe	Normalized to base ASCII
Smart Quotes & Dashes	“Hello”, En – Dash	"Hello", En - Dash	Converted to straight quotes/hyphens
Commercial Symbols	®, ™, ©	(R), (TM), (C)	Expanded to text equivalents
Auto-Fractions	¼, ½, ¾	1/4, 1/2, 3/4	Expanded to text equivalents
Math & Typographic	×, ÷, ±, …	x, /, +/-, ...	Converted to closest ASCII match
Ligatures	æ, œ, ß	ae, oe, ss	Expanded to base characters
Emojis	Hello 👋	Hello	Silently removed

Troubleshooting Length Errors

Because the nXus API safely expands special characters to ensure QuickBooks Desktop compatibility, a string that originally fit within a QuickBooks field limit might exceed it after sanitization. When this happens, QuickBooks will reject the request, and the nXus API will return a validation error.

If your application receives a length validation error from nXus, we recommend the following strategies:

1. Leave a Character Buffer

When defining validation rules on your own frontend or database, do not allow users to input the absolute maximum number of characters for strict QuickBooks fields.

• Example: If an Item Name allows 31 characters, restrict your UI input to 28 or 29 characters to leave room for potential symbol expansions.

2. Implement Client-Side Truncation

For non-critical text fields (like Memos or Item Descriptions), consider automatically truncating the string on your end before sending the payload.

3. Parse the Error Response

If a field is rejected by QuickBooks for length, the nXus API will return a 400 Bad Request with a message detailing the specific field that failed.

• Look for QuickBooks status codes related to string length in the error payload, and surface a user-friendly message in your application prompting the user to shorten their input.