Embedding the Inbox
Last updated
Last updated
This guide focuses specifically on embedding the Recrubo Inbox component into your application using iframes, which involves essential steps for authentication and initialization.
You can find the full list of available components in the section.
You can find the component reference for the Recrubo Inbox .
To grant a user access to the functionality within the iframes an authentication token
is required. Ensure your systems user has a corresponding user record within the Recrubo system see User for more information.
Using the following request you can create/retrieve an authentication token for the user by posting to the following path: public/v2/embed/authenticate
. This route expects your request to have the following body:
Now that you have acquired an authentication token you can initialize
the inbox or any other Recrubo iframe component. Initialization is carried out using the API, which allows your application to communicate the token and settings to Recrubo's app.
Even though the iframe source points to api.recrubo.app
, the second argument in postMessage
should be recrubo.app
since the components in the api subdomain redirect to our main domain which serves the webapp.
Aside from component specific settings you can override almost all colors used within our application, you do this by providing the theme
key in the first level of the settings object. The default theme is as follows:
This example overrides some of the default settings provided for the Inbox as well as a method to change the active conversation. Looking at the settings we disable the conversation select panel on the left (showTabPanel) as well as the candidate information on the right (candidateDetails). We also disable all functions that would allow the user to send a message or continue/pause the ongoing conversation. This is effectively a read-only mode of a single conversation. We also set the primary color in the theme to a bright red.
Like initialize there are more actions to execute; some of these are global but most will be component specific.
These actions are available with every component embedded through our V2 API:
updateSettings
getSettingsFor
getActionsFor
Default actions
, which are available on every component, are structured as follows:
And component specific actions
like so:
The arguments
key needs to be present in the form of an array
, even if there are no arguments to pass or just one.
The updateSettings
action is the exact same as the initialize
action in terms of payload. However behaviour wise it does not reauthenticate the user through their token, nor set all unspecified settings to their default values.
This action retains the already set settings and only updates the settings provided.
Soon to be implemented
This is more of a debugging tool if anything. You provide the component identifier you are interested in as the first and only argument and then the component will respond by posting a message back containing the default settings for the requested component.
The response posted back to the calling window will contain 3 keys, component
, current
and default
.
Where current
will contain the full settings object at the time of calling, and default contains the default settings.
Soon to be implemented
Much like getDefaultFor
this will mostly be used for debugging purposes and posts a message containing information about the actions available for the specified component, this again takes only one argument being the component identifier
The posted response contains 2 keys; component
and actions
. Where actions
is an object containing all component specific actions (therefor excluding the default actions
) with their name as the key.
The Recrubo Inbox component can be configured using the settings
key in the initialization object. The settings object contains a key per Component listed in .