---
feature_story: FS_37_57_36_29
feature_title: containers, envelopes, payloads
feature_status: TEST
---

All search/lookup and data on the server can be described by three concepts:
*   `envelope_container`
*   `data_envelope`
*   `envelope_payload`

These are layers similar to data wrapping for different protocol layers (packets into frames)<\br>
except for search application.

Think of a JSON objects.

The very first level of keys is the `envelope_container`, for example:

```json
{
    "some_meta_field_A": "meta_value_A1",
    "some_meta_field_B": "meta_value_B1",
    ...
    "some_meta_field_Z": "meta_value_Z3",
    "data_envelopes": [
        ...
    ],
}
```

Each `envelope_container` holds metadata to search some `data_envelopes`.

See also `EnvelopeContainer`.

Each `evnelope_container` includes 0 to N `data_envelope`-s which may look like this:

```json
{
    "type_A": "value_A1",
    "type_B": "value_B5",
    ...,
    "type_Z": "value_Z3",
    "envelope_payload": { ... },
}
```

See also `DataEnvelopeSchema`.

The first level keys in `data_envelope` is what `argrelay` will inspect and use for search.
*   Some of these keys have arbitrary arg type = arg value used in user search.
*   Some arg type might have special handling by `argrelay`, for example, `envelope_class`.
*   Some might be mandatory in certain situations.
*   Some might not have a simple value, but be an object instead, for example, `instance_data`.
*   etc.

One of the first level keys of `data_envelope` is called `envelope_payload` and this is the second concept -
its content is provided by user domain-specific application of `argrelay`.
It is data that is completely opaque for `argrelay` (`argrelay` just "relays" it around to feed user-specific actions).

