Async API + React HTML Components

This page covers the changes added to the Buzzy Frame API, giving full control to the user when calling API endpoints. Usage of such an API is explored as React components.

What's this?

The iframe API gives users access to pre-existing sandbox API endpoints without the need for message handling. We've exposed a set of asynchronous functions that can be awaited, this ensures that HTML components can be more deterministic as a result is guaranteed. Buzzy handles the message handling, making your HTML code snippets simpler!

This feature is current opt-in and you must enable it through the HTML field settings under "Enable Async API".

This page focuses on Async API behavior that is specific to Code Widgets. For shared row semantics such as metadata fields, linked-table structures, and embeddingRowID, use the REST API as the canonical source:

Script Placement

circle-exclamation

Table of Contents

Available Asynchronous Functions

Lifecycle and Context

initialise()

Initialises the code widget bridge and loads the current frame context. You should call this once before using other BuzzyFrameAPI methods.

Typical resolved value includes:

destroy()

Removes the message listener created by BuzzyFrameAPI. Use this when you need to explicitly clean up a widget instance.

Return

None. This method performs cleanup and returns undefined.

getResourceJSON()

Returns the most recently loaded resource context after initialise().

Return

The current resource context object loaded during initialise().

Typical shape:

getRowJSON()

Returns the current row context after initialise().

Return

The current row object loaded during initialise(). This follows the normal Buzzy row shape used elsewhere in the app and REST API.

Typical shape:

Data Management

circle-info

Working with Linked Table Fields: When inserting or updating rows that contain linked table (cross app) fields, you need to provide both a crossAppRowID and a value object. See the examples below and the REST API documentation for detailed patterns.

Canonical Row Semantics: Metadata fields such as _id, submitted, clientSubmitted, and embeddingRowID are defined in Row Metadata and Relationships.

Common Examples: For comprehensive examples showing the same operations across BuzzyFrameAPI, REST API, and Node.js client, see Common API Examples.

Insert a Row

Usage

Return

Linked Table Field Example

When inserting a row with linked table (cross app) fields using the async API, provide both the crossAppRowID and value object in the rowData:

Key Points:

  • crossAppRowID: The _id of the row in the linked table

  • value.label: The field name from the linked table to display

  • value.value: The actual display value from that field

See Also:

Update a Row

Usage

Return

Linked Table Field Update Example

When updating linked table (cross app) fields using the async API, provide the complete linked field structure:

Important Notes:

  • To update a linked table field, provide the new crossAppRowID and corresponding value

  • To clear a linked table field, set the field to null in rowData

  • The value.label should match a field name in the linked table

  • The value.value should be the display value from that field

See Also:

Remove a Row

Usage

Return

None.

Fetch Embedded Row Data

Use embeddingRowID for parent-child sub-table relationships. The canonical definition lives in Row Metadata and Relationships.

Usage

Return

Resource JSON for the current app context with the requested embedded rows resolved inside that resource structure.

This is not just a plain array. It returns the broader resource JSON object used by the runtime, with child row data included for the requested embedded table.

The exact structure depends on your app schema, but embedded row objects follow the standard Buzzy row shape.

Fetch All Embedded Data

Usage

Return

Nested row and sub-table data resolved recursively to N levels.

The exact structure depends on your schema. Expect a nested object or array structure containing the requested table or row plus all resolved child sub-table rows.

Fetch Data Table Rows

This method shares the same underlying row semantics as the REST microappdata endpoint. Use the REST docs for canonical filtering, metadata, and child-row query behavior.

Usage

Return

Array of row objects.

Typical item shape:

This method also supports built-in current-user filter descriptors such as:

Fetch Datatable Metadata

Fetches metadata for the current app context. This method uses the app context established during initialise() and does not require a datatable ID argument.

Usage

Return

Array of datatable metadata objects for the current app.

Typical item shape:

Filter Data View

filterMicroappView

Apply filters to a microapp view to show only specific data rows. This method allows you to create search and filtering functionality within code widgets.

Usage

Parameters

  • microAppID (string): ID of the data-table (microapp) to filter

  • embeddingRowID (string, optional): ID of the embedding row (used for sub-table filtering)

  • viewFilters (array): Array of filter objects using MongoDB query syntax

  • viewFilterIsMongoQuery (boolean): Whether to use MongoDB query language for complex filtering

  • filterContext (string): String identifier for the filter context to distinguish between different filters

Return

Example - Complete Contact Age Filter Implementation

Advanced Usage Patterns

When implementing filterMicroappView in production applications, follow these patterns demonstrated in the example above:

1. BuzzyFrameAPI Lifecycle Management

  • Always instantiate BuzzyFrameAPI outside React components to prevent re-initialization

  • Call buzzyFrameAPI.initialise() once during component mount

  • Set up microapp listeners immediately after initialization

2. Reactive Data Updates

  • Use addMicroappListener() to automatically refresh data when the underlying microapp changes

  • Track filter state with useRef to ensure listeners can access current filter parameters

  • Implement proper cleanup in useEffect return functions if needed

3. Error Handling and User Experience

  • Wrap all async operations in try/catch blocks

  • Provide meaningful error messages to users

  • Implement loading states for better user feedback

  • Include debug logging for development and troubleshooting

4. State Management

  • Use React state for UI-related data (loading, error, results)

  • Use useRef for values that need to persist across renders but don't trigger re-renders

  • Separate filter application from data fetching for better code organization

5. Performance Considerations

  • Debounce filter inputs to avoid excessive API calls

  • Cache filter results when appropriate

  • Use filterContext parameter to distinguish between different filter instances

This method applies the filters to the view outside the code widget, allowing users to create custom search interfaces that filter the main application data reactively.

getMicroappViewFilter

Gets the currently applied filter payload for a given filter context.

Return

The currently stored filter payload for that filterContext, or null if no filter has been stored yet.

Typical shape:

Shared State

Use shared state to store lightweight values for the current user session across cooperating widgets and widget interactions within the current app context.

Shared state is session-based only. It is not persisted as row data or app data, so it should be treated as temporary UI/runtime state rather than durable storage.

This is useful when you have multiple widgets across different screens that need to work from the same temporary state model. For example, in an accommodation booking app you might have a Discover widget, Search widget, Availability Calendar widget, Booking Summary widget, and Booking Request widget all sharing session state for the user's selected booking dates, guest counts, and other in-progress booking preferences.

setSharedState

Return

null. This method writes session state and resolves once the write has completed.

getSharedState

Return

The stored shared-state record for that key, or null if nothing has been stored yet.

Typical shape:

Send Notification

Usage

Parameters

  • email (string): Recipient email address

  • message (string, optional): Visible notification body

  • badgeCount (number, optional): Absolute badge number to send

  • channel (string, optional): push for push-only, inApp for unread notification only, or omit for default behavior

Code widgets automatically send the current appID behind the scenes. The request only succeeds if the logged-in user can edit that app.

Return

Typical resolved value:

Examples

Visible notification with default delivery

Badge-only push update (app only)

Use this when you want to programmatically change the badge number on a user's Apple device from a code widget. When you send only badgeCount with channel: 'push', Buzzy does not show a visible notification message and only updates the app badge number.

In-app only notification

Code widgets automatically use the logged-in user's auth token through the parent app, so you do not need to pass auth headers manually for this method.

Query Options (Pagination) and Filtering

When fetching embedded row data, you might to do pagination, filtering, and/or limit the number of results that you get. Buzzy uses MongoDB under the hood, as such, view filters follow the rules for MongoDB queries. This includes support for geo/spatial queries using sortValGeometry - see geo/spatial query examplesarrow-up-right for more details.

Query Options (Pagination and Data Limits)

Query options allow you to control the number of results you get back from the query, as well as allowing you to do pagination using the skip parameter.

For paging, always pass both queryOptions.limit and queryOptions.skip. The subLimit parameter is only a fallback subscription limit for older or non-paged calls. If queryOptions.limit is missing, Buzzy uses subLimit as the limit. If both are missing, the code-widget bridge defaults subLimit to 50.

This means a paging loop should use:

Do not rely on subLimit as the page size for paged reads. Use queryOptions.limit for the page size and queryOptions.skip for the offset.

Common supported MongoDB aggregation parameters:

More info on Sorting: The data fetched from the Microapp can be sorted. The order and field parameters are used in the searchFilter to specify which Microapp sort field and if it is ascending or descending. The sort fields are configured in the Microapp Results Tab. Sort field 1 corresponds to the field value 1 and so on. Where order is either 1 = ascending or -1 = descending.

Example fetching microapp rows using Sort Field 1.

View Filters (Filtering)

In cases where you might want to filter the results based on the value of a field, you can query based on the value of a field of the data table row. viewFilters is an array of view filters to be used, as such you may filter many views as they are scoped to the data table ID (resourceID).

Combining the Above Concepts, see the following example with filtering and pagination included:

In the example above, the query will fetch rows where the sortVal contains the word "Lasagna", in this case, the sortVal is referencing the data table row title (the recipe title). The query options them limit the rows to only 1 row, while skipping 0. If we were doing some pagination, when a user clicked a "Next Page" button, we could change the skip to 1 so it would get the next recipe that satisfies the filters.

MicroAppChild Management

createMicroappChild

Creates a new MicroAppChild entry.

For backward compatibility, microAppResourceID and appID are also accepted as aliases for microAppID and rowID.

Example usage for file upload:

Return

The created MicroAppChild record.

Typical shape:

getChildItemsByField

Retrieves all MicroAppChild entries for a specific parent app item and field.

For backward compatibility, appID is also accepted as an alias for rowID.

Example usage for fetching images:

Return

Array of MicroAppChild records for that parent row and field.

Typical shape:

readMicroappChild

Retrieves a single MicroAppChild entry by ID.

Return

A single MicroAppChild record.

updateMicroappChild

Updates the content of a MicroAppChild entry.

Example usage for updating file URL:

Return

The updated MicroAppChild record.

removeMicroappChild

Deletes a MicroAppChild entry.

Return

The removed MicroAppChild record.

copyS3File

Copies an existing file between two S3-backed resources and returns the new file URL or key data from the server.

Return

Signed read URL string for the copied file.

uploadMicroAppChildToS3FromUrl

Uploads a file to a MicroAppChild field from a URL or data URL.

If url is a browser blob: URL, BuzzyFrameAPI automatically converts it to a data URL before upload so it can be transferred safely across the iframe boundary.

Return

Object containing the signed read URL for the uploaded file.

Typical shape:

Functions and Constants

runAppFunction

Runs an app function with optional payload and row context.

Return

The response returned by the underlying Buzzy function. The exact shape depends on that function's implementation.

If your function follows a structured API-style response, expect something like:

getConstant

Retrieves a non-secret app constant by name.

Return

Lookup result object for the requested constant.

Typical shape:

Navigates to a different screen within the same app.

Example usage:

Return

None. This method triggers navigation and does not resolve a payload.

getScreenID

Helper method to get the screenID for navigation.

Return

Screen ID string when found, otherwise null.

getScreenURL

Builds a route-backed screen URL without navigating.

Return

Absolute URL string for the requested route-backed screen, or null if no route-backed URL can be built.

openURL

Opens a URL using Buzzy's runtime link semantics.

newTab defaults to false.

Return

Result object describing whether the URL was accepted and how it was normalized.

Typical shape:

close

Closes the current overlay or screen context.

Return

None. This method closes the current context and does not resolve a payload.

closeAll

Closes all open overlay or child screen contexts in the current stack.

Return

None. This method closes open child contexts and does not resolve a payload.

Organization and Team Management

createOrganization

Creates a new organization.

Return

Parsed JSON response from the matching REST endpoint. Typical shape mirrors the REST insertorganization response:

readOrganization

Reads an organization by ID.

Return

Parsed JSON response from the matching REST endpoint.

Typical shape:

updateOrganization

Updates an organization's information.

Return

Parsed JSON response from the matching REST endpoint, typically a success object with the updated organization in body.

deleteOrganization

Deletes an organization.

Return

Parsed JSON response from the matching REST endpoint, typically a success object confirming deletion.

createTeam

Creates a new team within an organization.

Return

Parsed JSON response from the matching REST endpoint, typically containing the created team ID in body.

readTeam

Reads a team by ID.

Return

Parsed JSON response from the matching REST endpoint containing the team record in body.

updateTeam

Updates a team's information.

Return

Parsed JSON response from the matching REST endpoint, typically a success object with the updated team in body.

deleteTeam

Deletes a team.

Return

Parsed JSON response from the matching REST endpoint, typically a success object confirming deletion.

createTeamMember

Adds a member to a team.

Return

Parsed JSON response from the matching REST endpoint, typically a success object for the created membership record.

readTeamMember

Reads a team member by team ID and user ID.

Return

Parsed JSON response from the matching REST endpoint containing the membership record in body.

updateTeamMember

Updates a team member's role.

Return

Parsed JSON response from the matching REST endpoint, typically a success object with the updated membership record in body.

deleteTeamMember

Removes a member from a team.

Return

Parsed JSON response from the matching REST endpoint, typically a success object confirming removal.

Listen for Updates

Usage

Register a listener function for a given microapp (aka data table).

This method registers the listener and does not return a data payload.

Whenever data is added or updated that fits the query you have running on the given microapp, the supplied listener function will be executed. In the native app version, this function will also be run if the user initiates a refresh by dragging down on the screen.

Typically this would be used to re-run your query and set the results to a state variable, and thus trigger re-rendering of your fetched data whenever it is updated.

The listener will be passed on object with these properties:

  • microAppID - the id that passed into the listener

  • isUserRefresh - true if this is a user initiated refresh

  • timestamp - timestamp of the update that triggered the listener

Code Example

Preamble

The API works best within the context of a sandbox iframe (see the Code Widget documentation for security considerations). In our examples and testing, we utilise the Reactarrow-up-right front-end library to construct HTML snippets. We've found that the behaviour of UI elements using React for HTML components allows for more granular control over rendering and state. As such, in the examples shown on this page, we will use React with functional componentsarrow-up-right.

Buzzy HTML Field Settings

Due to the usage of React, we want to disable handlebars and opt-in to the new Async API. This is easily accomplished in the settings panel of the HTML field definition:

Our Example Data table Layout

As a reference for the code snippet, the fields and set up of the data tables referenced in the code example are provided below:

Fruit Reports (Data table)

  • Fruit Report (Text)

  • Date (Datetime)

  • Fruit Counters (Sub table)

  • Graphic-HTML (HTML Field)

Fruit Counters (Sub table)

  • Fruit Type (Select list)

  • Number (Count)

  • Date Counted (Datetime)

Code

Result

With some data table rows, the above example provides the following output in Buzzy:\

Advanced Examples

Example 1: Course Enrollment with File/Image Copying

This example demonstrates how to create a course enrollment system that:

  1. Creates a copy of a course template for a user

  2. Copies all associated questionnaires, questions, and options

  3. Handles file and image copying between templates and user instances

  4. Uses navigation to guide the user through the process

This example demonstrates several key features:

  • Using getChildItemsByField to fetch file and image attachments

  • Using createMicroappChild to copy attachments to new rows

  • Using navigate to guide users through the enrollment process

  • Handling complex data relationships and maintaining referential integrity

Example 2: Course Unenrollment with Cleanup

This example shows how to properly remove a course and all its associated data, maintaining referential integrity:

This example demonstrates:

  • Proper cleanup of nested data structures

  • Using navigate to show processing and completion states

  • Maintaining referential integrity during deletion

  • Error handling and user feedback

Limitations

The current iteration of the new API is still under development. There are a number of key issue yet to be resolved:

Last updated