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
Warning
You must place the <script> inside the <body> of your custom HTML code.
This is important as the Buzzy Frame API is loaded in the head and may not be available due to loading order.
Table of Contents
Available Asynchronous Functions
Lifecycle and Context
initialise()
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()
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()
getResourceJSON()Returns the most recently loaded resource context after initialise().
Return
The current resource context object loaded during initialise().
Typical shape:
getRowJSON()
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
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_idof the row in the linked tablevalue.label: The field name from the linked table to displayvalue.value: The actual display value from that field
See Also:
REST API insertmicroapprow - REST API equivalent
microappdata/row - Understanding linked table field structure
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
crossAppRowIDand correspondingvalueTo clear a linked table field, set the field to
nullinrowDataThe
value.labelshould match a field name in the linked tableThe
value.valueshould be the display value from that field
See Also:
REST API updatemicroapprow - REST API equivalent
microappdata/row - Understanding linked table field structure
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 filterembeddingRowID(string, optional): ID of the embedding row (used for sub-table filtering)viewFilters(array): Array of filter objects using MongoDB query syntaxviewFilterIsMongoQuery(boolean): Whether to use MongoDB query language for complex filteringfilterContext(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
BuzzyFrameAPIoutside React components to prevent re-initializationCall
buzzyFrameAPI.initialise()once during component mountSet up microapp listeners immediately after initialization
2. Reactive Data Updates
Use
addMicroappListener()to automatically refresh data when the underlying microapp changesTrack filter state with
useRefto ensure listeners can access current filter parametersImplement proper cleanup in
useEffectreturn 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
useReffor values that need to persist across renders but don't trigger re-rendersSeparate 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
filterContextparameter 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
getMicroappViewFilterGets 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
setSharedStateReturn
null. This method writes session state and resolves once the write has completed.
getSharedState
getSharedStateReturn
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 addressmessage(string, optional): Visible notification bodybadgeCount(number, optional): Absolute badge number to sendchannel(string, optional):pushfor push-only,inAppfor 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 examples 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
runAppFunctionRuns 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
getConstantRetrieves a non-secret app constant by name.
Return
Lookup result object for the requested constant.
Typical shape:
Navigation
navigate
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 React 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 components.
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:
Creates a copy of a course template for a user
Copies all associated questionnaires, questions, and options
Handles file and image copying between templates and user instances
Uses navigation to guide the user through the process
This example demonstrates several key features:
Using
getChildItemsByFieldto fetch file and image attachmentsUsing
createMicroappChildto copy attachments to new rowsUsing
navigateto guide users through the enrollment processHandling 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
navigateto show processing and completion statesMaintaining 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