Data Formatting

Suggest Edits

Bringg uses RESTful data formatting conventions to maintain consistency across the API and Bringg platform.

Parameter types

Parameter types determine how data is formatted in APIs and correspond to the way that the included information is stored in the databases that run behind Bringg.

TypeDescriptionExample
arrayAn array is a list of objects or strings (records or attributes) and the data pertaining to each.
For example, in Bringg, an array of skills is a list of required skills needed to fulfill an order.		 "required_skills": [ "fridge installation", "heavy lifting" ]
booleanA boolean defines if a parameter is true or false.
For example, you can indicate if linked tasks should be created for a new order.		"create_linked_tasks": true
doubleA double is used to represent very large or very small numbers (it allows for up to 15 digits after the decimal point).
For example, latitude and longitude data is included as a double.		"lat": 40.7076612, "lng": -74.0031032,
floatA float takes up less memory space than a double (it allows for 7 digits after the decimal point). Floats are not commonly used in Bringg.
IntegerAn integer is a whole number without a decimal point. Integers are often used to indicate a Bringg ID or to correspond with an option from a list.
For example, the status 2 corresponds to the "on the way" status.		"status": 2,
objectAn object contains a single record, such as a product, customer, or order. Objects can also contain additional objects."customer": { "allow_sending_email": true, "allow_sending_sms": true, "name": "Alice Adams", "email": "[email protected]" },
stringA string is a chunk of characters (text, digits, or symbols). For example, a phone number or a customer name is included as a string. "name": "Alice Adams"

Datetime

ISO 8601

Bringg uses ISO 8601 formatting for most timestamp (or datetime) parameter values. This ensures consistency regardless of system, user, and customer regions. Bringg translates this to a friendly date and time in the UI and automatically converts it to the user's time zone, taking Daylight Savings into account. For example:

2024-03-11T14:00:00.000Z is March 11, 2024, at 14:00 (2:00 PM) in the Coordinated Universal Time (UTC) time zone. For a Bringg user in Denver, which is located in UTC-6, the time will appear as 8:00 AM.

You can send more precise datetime information to Bringg using an offset. For example:

2024-03-11T14:00:00-05:00 indicates that the local time is 5 hours behind UTC and becomes 2024-03-11 at 9:00 AM.

🚧

Caution

Bringg does not convert time zones or account for Daylight Savings Time for datetime values that include an offset. If you send 2024-03-11T14:00:00+05:00, Bringg will only display time time at UTC-5.

Let's break down the datetime format:

2024-03-11T14:00:00.000Z:

  • 2024-03-11 represents the date, formatted as YYYY-MM-DD, where YYYY is the four-digit year, MM is the two-digit month, and DD is the two-digit day.

  • T is a delimiter that separates the date from the time.

  • 14:00:00.000 represents the time, formatted as hh:mm:ss.sss, where hh is the two-digit hour, mm is the two-digit minute, ss is the two-digit second, and sss is milliseconds.

  • Z indicates that the time is in UTC, meaning no timezone offset is applied.

2024-03-11T14:00:00+05:00 includes an offset:

  • +05:00 indicates that the local time is 5 hours ahead of UTC.
  • -05:00 would indicate that the local time is 5 hours behind UTC.

Unix Epoch Timestamps

Bringg uses Unix Epoch timestamps for some values. This system counts the time since January 1, 1970 at 00:00:00 UTC. This formatting is useful for calculating durations and avoids the complexity of handling time zones and Daylight Savings Time. For example:

1710328302 is the number of seconds since January 1, 1970, and converts to March 13, 2024, at 11:05:05 AM.

You can convert Unix Epoch timestamps using a calculator such as https://www.unixtimestamp.com/.

Phone numbers

Bringg uses the regular expression pattern ^[+]?[(]?[0-9]{3}[)]?[-s.]?[0-9]{3}[-s.]?[0-9]{4,9}$ to match and validate phone numbers with various formats. Each symbol in the expression matches a section or symbol in the phone number:

  • ^ asserts the start of the string.
  • [+]? matches an optional plus sign (+) at the beginning of the number.
  • [(]? matches an optional opening parenthesis (().
  • [0-9]{3} matches exactly three digits (0-9).
  • [)]? matches an optional closing parenthesis ()) if an opening parenthesis was present.
  • [-s.]? matches an optional hyphen (-), whitespace (s), or period (.) separator.
  • [0-9]{3} matches exactly three digits (0-9).
  • [-s.]? matches an optional separator after the second group of three digits.
  • [0-9]{4,9} matches a group of 4 to 9 digits (0-9).
  • $ asserts the end of the string.

Here are some examples of phone numbers that would match this pattern:

  • +123-456-7890
  • (123) 456-7890
  • 123.456.7890

Note that the pattern allows for flexibility in terms of the presence of optional elements like the plus sign, parentheses, and separators. The last group of digits can range from 4 to 9 digits, accommodating phone numbers with or without extension numbers.

Updated about 2 months ago