Skip to main content
When you create a Nash order, these validations run before the order is accepted.

​
Address & location validation

  • Address input exclusivity:
    • An error is raised if you provide both pickupAddress and pickupPlaceId (or the dropoff equivalents). You must use one or the other.
    • An error is raised if you provide address components (e.g., pickupAddressFormattedStreet) along with pickupAddress or pickupPlaceId.
  • Address input requirement: If no store location ID is provided, Nash requires one of the following for both pickup and dropoff:
    1. A single-line address string (pickupAddress / dropoffAddress).
    2. A Google Place ID (pickupPlaceId / dropoffPlaceId).
    3. A set of address components (street, city, zip, etc.).
    • If none of these are present, a “required field” error is added for the address.
  • Store location logic:
    • If a pickupStoreLocationId or pickupExternalStoreLocationId is provided, Nash looks up the corresponding store location.
    • Existence check: Fails if the store location ID doesn’t exist for that organization, or if the store has been deleted.
    • Automatic store creation: If an external store location ID is given but not found, Nash checks an organization preference for automatically creating store locations. If enabled, it creates a new store location from the order’s pickup details.
    • Default field population: If a valid pickup store location is found, Nash populates the order’s pickup fields (name, phone, email, instructions) from the store, unless those fields were already provided in the request.
  • Geocoding and parsing:
    • If a raw pickupAddress or dropoffAddress string is provided, Nash parses and geocodes it to get coordinates (latitude/longitude). Parsing failure raises an error (for example, “Address not found”).
    • Nash performs the same parsing and geocoding for pickupPlaceId and dropoffPlaceId.
  • Identical location check:
    • Nash raises an error if pickupPlaceId and dropoffPlaceId are the same.
    • After parsing, Nash compares the final parsed pickup and dropoff address components and raises an error if they’re identical.
  • Cross-country check: Fails if the parsed pickupAddressCountry and dropoffAddressCountry are not the same.
  • Distance check:
    • Nash calculates the straight-line distance between the pickup and dropoff coordinates.
    • That distance is checked against an organization-specific maximum delivery distance preference, and fails if it exceeds the maximum.

​
Required & conditional fields

  • Core required fields: Checks that a value is present for: valueCents, pickupPhoneNumber, dropoffPhoneNumber, deliveryMode.
  • Contact name requirement:
    • Requires either pickupFirstName or pickupBusinessName to be present.
    • Requires either dropoffFirstName or dropoffBusinessName to be present.

​
Data type & format validation

  • Integer fields: Verifies that valueCents, tipAmountCents, and itemsCount are valid integers.
  • Float/decimal fields: Verifies that dimensional fields (weight, height, width, depth, volume) are valid decimal numbers and are greater than 0.
  • Units: Nash stores weight in kilograms and dimensions in centimeters. Send those units and you don’t need to say so. To send imperial values instead, declare the unit and Nash converts on ingest:
    • weightUnit accepts lb or lbs (case-insensitive) and converts weight to kilograms. Omitting it, or sending kg, stores the value as given. Any other value is rejected with ORDER_INVALID_WEIGHT_UNIT.
    • lengthUnit accepts in, inch, or inches (case-insensitive) and converts height, width, and depth to centimeters. volume is read as cubic inches and converted to cubic centimeters, since one unit covers all four fields. Omitting it, or sending cm, stores the values as given. Any other value is rejected with ORDER_INVALID_LENGTH_UNIT.
    • Declaring a unit without the matching value is harmless — weightUnit with no weight converts nothing.
  • Order value: Checks that valueCents is greater than 0.
  • Item count: Checks that itemsCount, if provided, is at least 1.
  • Name fields: Checks that all name fields (pickupFirstName, etc.) are strings and do not exceed a maximum length (80 characters).
  • Phone numbers:
    • Checks that pickupPhoneNumber and dropoffPhoneNumber are valid phone numbers for the corresponding country.
    • If the number is invalid but the organization has a default backup phone number configured, Nash uses the backup number instead of failing.
  • Items: If the items field is provided, Nash validates that each entry in the list is a valid item structure.
  • Order metadata:
    • Nash validates that orderMetadata has no more than 15 key-value pairs, and that all values are simple scalar types (string, int, float, bool).

​
Enum & ID validation

  • Delivery mode:
    • Ensures deliveryMode is one of the allowed values (now or scheduled).
    • If mode is now, Nash nullifies all datetime fields.
    • If mode is scheduled, Nash requires at least one of the datetime fields (pickupStartTime, etc.) to be set.
  • Currency:
    • If a currency is provided, Nash checks it against the list of supported currencies.
    • If no currency is provided, Nash infers it from the pickupAddressCountry.
  • Requirements: Ensures all provided requirements are supported (see Order requirements), unless it’s a custom: requirement.
  • Vehicle size: Ensures minimumVehicleSize is one of the supported vehicle sizes.
  • Dispatch strategy: If dispatchStrategyId is provided, Nash confirms it exists, belongs to the organization, and isn’t deleted.
  • Delivery window: If deliveryWindowId is provided, Nash checks that it’s a valid, active window.
  • External ID uniqueness: If an externalId is given, Nash ensures no other order in the same organization already uses that ID.

​
Datetime validation

  • Parsing: Parses all provided datetime strings (pickupStartTime, pickupEndTime, dropoffStartTime, dropoffEndTime) into datetime objects, handling both UTC and timezone-localized inputs. Fails if a string is not a valid date format.
  • Chronological order:
    • pickupStartTime must be earlier than pickupEndTime.
    • dropoffStartTime must be earlier than dropoffEndTime.
    • pickupStartTime must be earlier than dropoffEndTime.
    • pickupEndTime must be earlier than dropoffEndTime.