Embedded components

Unified.to provides a suite of pre-built front-end components (i.e. embedded components) for you to use in your app. These components display a list of your activated integrations:

  • Authorization: Ask customers to authorize access to their third-party accounts,
  • Sign-in: Authenticate users so they can sign into your app, or
  • Public Directory: Display a list of your integration so your users can learn about your third-party API offerings.

Add the embedded components to your app

To use any one of these components in your app:

  • Make sure you've activated some integrations first. You can do so at app.unified.to/integrations.
    • If your goal is to use the Sign-in component, be sure to activate integrations that support Authentication.
  • On app.unified.to, click on Embedded components and select which of the widgets you want to use from the tab.
  • Configure how you want the component to behave under the Configuration tab.
  • View and copy the code to add to your app under the Embedded Code tab.
  • Important: Under the Options tab, be sure to select the correct permissions scopes that the integrations you activated are expecting to receive. By leaving these options blank, Unified.to will request access to all possible scopes. To learn more about scopes, see: Understanding scopes.

Embedded Authorization Components

Reactnpmjs.com/package/@unified-api/react-directory
Angularnpmjs.com/package/@unified-api/angular-directory
VueJSnpmjs.com/package/@unified-api/vuejs-directory
Sveltenpmjs.com/package/@unified-api/svelte-directory

Manually Authorizing Connections

If you do not want to use our pre-built authorization components, nor want to copy our component source code and make changes, then you can use our API

This is the flow to follow in your application with your end-user:

  1. you redirect your user to our auth URL. Make sure to include a success_redirect, failure_redirect, and permissions. Also include either state or external_xref.
  2. Your end-user will authorize the connection
  3. if they cancel, then we return them to the failure_redirect
  4. If they authorize the connection, we then test their API credentials to see if it has the valid permissions
  5. If that fails, then we redirect them back to the failure_redirect and also include an error message with a string denoting the error
  6. If it succeeds, then we redirect them to the success_redirect and add an id URL value of the connection ID
Are we missing anything? Let us know
Was this page helpful?