Entries
All the data sent by someone to an Inbox is called an Entry. In Threads and Stores, a user must be assigned to the Module to send data. In Inboxes, however, anyone who has Inbox ID can send a reply (assuming they have the Bridge URL and Solution ID).
Inboxes allow users to receive encrypted entries, either from external or internal sources.
-
Internal sources are people who have access to an Inbox, or are simply registered in a given Context. Those users are known to your application, and their entries can be linked to their accounts.
-
External sources are people from the outside; they do not have an account linked with your app. For example, someone who fills out an online contact form without the need to create an account.
Sample code on this page is based on the initial assumptions
Define Data Structure
Inbox's architecture does not require you to use a specific data structure inside the entries. Before working with Inboxes, define the structure of your entries.
We recommend future-proofing your entries by choosing an easily modifiable format. It is a good idea to include both a type and a version field in the structure.
Example: Form with Text Answer
The type field allows future support for different types of entries like: "select_answer", or "multi_select".
And in case of changing the schema, you can always distinguish between them using "version" field.
Remember that this is only an example and you should consider your app's requirements and limitations.
Submitting Entries
To submit an entry, you need:
- URL of your PrivMX Bridge Instance
- Solution ID with at least one Inbox created
- ID of the Inbox to submit the entry
If you need more information about how to create an Inbox, go to Creating an Inbox.
Accessing via Public API
PrivMX Endpoint provides different ways to connect to a PrivMX Bridge instance.
When using "public" connection you don't have to pass a private key. A random private key will be generated for each connection. The public connection provides only the methods related to sending Inbox entries and retrieving public metadata related to the Inbox.
Public Connection
To submit data as unregistered user you have to connect using connectPublic(...) and then - prepare and send an Entry.
You have to pass required Bridge URL and Solution ID. Then use an inboxApi.
Submitting Entries
Fetching Entries
Fetching entries requires decoding them back into their original format. Depending on your data structure, you will need to parse and decode the fetched entries.
The process for fetching entries heavily depends on your entry format. Refer back to Define Data Structure if you need guidance on how to structure your entry.
Fetching entries requires a secure private connection.
Fetching the most recent Entries submitted to Inbox:
Working With Files
Inbox entries can include any number of files (in accordance with the predefined Inbox file configuration).
Each file may include its own public and private metadata to store additional information.
For example, to include file name and mimetype information, pass this data as JSON to the publicMeta (or privateMeta, if the file name contains sensitive information):
For example:
Attaching Files
Sending entries with attached files follows a similar process to sending entries without files. The main difference is that you must create file handles for each file and stream their content.
Preparing Entry
For each file you want to send, create a file handle. You can provide additional data, e.g. file name or its metadata.
If you’re creating a questionnaire, you can relate files with questions by putting question info in the file's metadata.
Sending File Contents
For large files, it is recommended to stream the file content in small buffers rather than loading the entire file into memory. PrivMX Endpoint divides those buffers if required, then streams them to your PrivMX Bridge.
Sending File Entry
Finally, send the entry in the same way as described before:
Fetching File Entries
Entries include only file metadata, without their contents. Similar to entries data, you have to decode them before using.
For example, if you saved name and metadata of a file in its privateMeta,
you can read them like this:
We use cookies on our website. We use them to ensure proper functioning of the site and, if you agree, for purposes such as analytics, marketing, and targeting ads.