What a parser is
A parser is the field definition of your events for one vertical: for each field it sets the name, the label people read, the type and section, whether it is required, whether it travels over SMS and other low-bandwidth channels, and how it is written there in compact form, with a short code (sms_code) and a byte budget (max_bytes).
Parsers are organised as models. A model has a code of 1 to 4 lowercase letters or digits (model_code), unique across all the verticals of your tenant, and a sequence of versions. Every version is immutable: changing the fields creates the next version, and old versions stay stored and are never deleted, so a message written with an old version can always be read. One version of a model is active at a time.
Parsers belong to your tenant. The fields marked Show to team travel with each mission (parser_schema on GET /v1/missions/my and GET /v1/missions/:id), so the apps your field teams use know exactly which fields to show and how to encode them. Show to team is also the limit of what a field operator sees of an event: the mission carries a snapshot of those fields’ values, and GET /v1/events/:id returns a field operator only those fields (see Get event). A vertical with no active parser shows your teams no event data at all until one is active.
Field attributes
string
required
Stable identifier of the field inside the model, 1 to 64 characters. Protection rules and versions track fields by
id.string
required
Key of the field in the event payload, up to 40 characters.
string
required
What people read in the apps and in the dashboard, up to 60 characters. Never sent over SMS.
string
required
Short code written in SMS and other compact channels, 1 to 4 characters, unique in the model. The legend of a version maps each code to its label.
string
required
string, number, boolean, gps, text, timestamp, enum, phone, email, address or hardware_id. A gps field is written with 4 decimal places by default (about 11 metres).string
default:"custom"
core, location, human, hardware, team or custom. Groups the fields in the apps.string
default:"\"\""
Help text for the people filling the field, up to 300 characters.
boolean
default:"true"
A disabled field is kept in the model but not shown, not sent and not required.
boolean
default:"true"
Whether the field travels with the mission and is visible to the field team. This is the limit of what a field operator sees of an event.
boolean
default:"true"
Whether the field is written in SMS and other compact channels. Direct identifiers are off by default in the factory models; you decide.
boolean
default:"false"
The field must be present for the event to be accepted.
boolean
default:"false"
Marks a field as personal data. Personal data fields are on by default in the factory models and are yours to enable, disable or remove under data minimisation; wede never pre-loads full identity documents or card numbers.
integer
required
Byte budget of the field in compact channels, 1 to 160, counted in UTF-8 (an accented letter counts as 2).
boolean
default:"false"
A locked field cannot be removed or disabled. You can set it in version 1 of a model you create; after that only wede changes this flag, through a narrow endpoint that never reads your schema.
boolean
default:"false"
Marks the field whose options are event types of your catalog: its
options[].action_code must exist in the catalog of the vertical.object[]
For
enum fields, up to 64 options with code (1 to 4 characters, written in SMS), label (up to 60 characters, read in the apps) and, for the type field, action_code (the event type code in your catalog).SMS encoding and the legend
In SMS and other compact channels only the short codes travel: thesms_code of each field and the code of each option. The full labels live in the legend of the version and are shown by the apps and the dashboard, never sent. Every compact frame carries the model (_m) and the version (_r) it was written with, so the receiving side reads it with the right legend even if the model has changed since. The vertical (_v) is only written when there is no model.
Every factory model fits in one SMS: its enabled send_by_sms fields, filled to their max_bytes, plus the protocol overhead, stay within the 95 bytes of payload a single SMS frame carries once the envelope is counted. Longer messages are split into up to 32 frames and reassembled; the parser editor in the dashboard shows how many SMS an event takes in the worst case and warns when a model is one digit away from needing a second frame (the version number grows at 100). Sizes are counted in UTF-8 bytes.
When wede itself notifies recipients of an event by SMS, the message carries a compact header (a short event identifier, the event type, the priority and the zone), never the event payload.
Field protection
wede checks every schema change against the version currently stored, never against what the client claims. Two layers apply:
A change that breaks a rule is rejected as a whole with
403:
reason values: integrity_core_cannot_be_removed, integrity_core_cannot_be_disabled, integrity_core_cannot_be_unlocked, locked_field_cannot_be_removed, locked_field_cannot_be_disabled, lock_flag_change_requires_wede_admin.
Fields marked personal_data: true are not protected by these rules. Under data minimisation (GDPR article 5), only collect and send the personal data your operation needs: you can enable, disable or remove these fields like any other.
Every rejected attempt is recorded in the audit log as parser.update.rejected and counted in the compliance report.
Factory models
Every vertical has at least one factory model; healthcare and banking have two. When a vertical is assigned to your tenant and has no parser yet, wede creates version 1 of its factory model for you.GET /v1/parsers/templates lists the factory models of your verticals, and POST /v1/parsers/from-template creates a model from one of them, for example the second factory model of a vertical.
In every factory model event_id and timestamp are locked, personal data fields are marked personal_data, direct identifiers are not sent by SMS by default, and full identity documents and card numbers are never included. Review the model before going live, disable what you do not need and add your own fields within the protection rules.
Versions
A version never changes once created. Updating theschema of a version with PATCH /v1/parsers/:id creates the next version of the same model (version increases by one) and returns it with 201 and previous_id; the previous version stays stored. name, description and is_active change in place without a new version, and so does the locked flag, because none of them changes what travels in messages.
Activating a version with is_active: true deactivates every other version of that model. A model always keeps one active version: the active version cannot be turned off or archived (409 active_version_required), so make another version active first. DELETE /v1/parsers/:id archives a version that is not active: it disappears from the list and from the apps, is never deleted, and GET /v1/parsers?include_archived=1 still returns it, so old messages written with it can be read.
Activating a version whose type field points to event types that are not in your catalog is refused with 422 parser_type_missing and the list of missing codes: create the types first (see Event types).
Endpoints
Every parser object returned includes the worst case size of the version in compact channels (
sms_size), so an integration can check it before activating.
Roles and access
Parsers are managed with a user session. API keys receive403 forbidden.