## Compliance Certifications
At Alloy Automation, we take security very seriously. In fact, we take a number of steps to mitigate any security risk. Alloy Automation is [SOC 2 Type I and II Compliant](https://us.aicpa.org/interestareas/frc/assuranceadvisoryservices/aicpasoc2report), SOC3, HIPAA, GDPR, and CCPA compliant. We undergo a regular SOC2 audit yearly. We work with a 3rd Party monitoring system to ensure continuous compliance. Potential customers can reach out to us to request a copy of our SOC 2 Report.
SOC 2 is a report based on the Auditing Standards Board of the American Institute of Certified Public Accountants' (AICPA) existing Trust Services Criteria (TSC). The purpose of this report is to evaluate an organization’s information systems relevant to security, availability, processing integrity, confidentiality, and privacy.
In addition to SOC 2, we are HIPAA, CCPA and GDPR Compliant and offers endpoints to allow customers to easily request data deletion in compliance with GDPR standards.
# GDPR Policies
Source: https://docs.runalloy.com/embedded/certifications/gdpr
To comply with GDPR, we allow you to remove any customer data for any given user. By using Alloy Embedded, it is your responsibility to remove any and all user data upon a user's request in accordance with European Union law.
To remove user data, you can invoke our [DELETE users/logs](/reference/embedded/delete-logs-for-a-user) endpoint.
# HIPAA Policies
Source: https://docs.runalloy.com/embedded/certifications/hipaa
Alloy Automation is compliant with the Health Insurance Portability and Accountability Act (HIPAA).
To ensure compliance, Alloy Automation has partnered with [Secureframe](https://secureframe.com/frameworks/hipaa). If you have any questions about our HIPAA compliance, please contact your account rep.
# SOC 2
Source: https://docs.runalloy.com/embedded/certifications/soc-2
Alloy Automation maintains compliance with the Service Organization Control Type 2 standards. Alloy Automation is both SOC2 Type I and SOC2 Type II compliant. Further, Alloy Automation maintains SOC3 compliance as well.
We undergo an annual audit of all systems to ensure strict adherence to SOC requirements. If you are a prospective customer looking to obtain a copy of our SOC2 report or if you have any questions on our controls, please contact your account rep.
# Concurrency
Source: https://docs.runalloy.com/embedded/concurrency
## Overview
In this guide, we'll take a look at how Alloy handles concurrency when running workflow executions. Understanding concurrency is important to having a solid grasp of our infrastructure.
## How it Works
To understand how concurrency works at Alloy, let's take two scenarios:
* Scenario 1: You have a single workflow that listens for new records created in BigCommerce and proxies those events over to your API. Let's assume this workflow receives 5,000 events in the first hour.
* Scenario 2: You've set up two workflows, one that receives customer sign-up events and adds them to a list in klaviyo, and a second workflow that receives Clicked Email events from Klaviyo and proxies those events to your API.
Alloy handles concurrency by spreading out workflow executions at the Workflow level. In other words, a workflow execution, or execution for short, represents any given job associated with a workflow. In Scenario 1, the rate at which Alloy can process the event and send it to your API is largely dictated by the rate-limiting of your API. If BigCommerce sends the first 1,000 events to Alloy over the course of a minute, we wouldn't want to immediately send those 1,000 events to your API if it has a 60 request-per-minute limit. Alloy instead adds those requests to a queue spread out over time to avoid having to handle rate-limit errors with retries. When the remaining 4,000 events are received over the course of an hour, they will be queued up to run after the last batch of events if there are still any outstanding.
In Scenario 2, if Alloy receives a customer signup event and clicked email event simultaneously, both workflows will execute simultaneously. These two workflows function independent of one another, and events received by one will not impact the event scheduling of the other.
## Wrapping Up
In this tutorial, we took at look at how Alloy handles concurrency across workflow executions.
# Custom Action
Source: https://docs.runalloy.com/embedded/custom-action
The Custom Action connector allows developers to define and execute arbitrary API requests using an existing application's authenticated credentials.
### Base API URL
When making requests against our APIs, it's important to select the EU data center if you intend to have all data pass through the European Union. Note that any users, credentials, etc created in the EU data center will not be accessible in the US data center and vice versa.
### Base API URL
When making requests against our APIs, it's important to select the US data center if you intend to have all data pass through the United States. Note that any users, credentials, etc created in the US data center will not be accessible in the EU data center and vice versa.
With Custom OAuth, you can supply your own **Client Id** and **Client Secret**and Alloy Embedded will use those credentials to make the appropriate requests on your behalf. The result of this is that when an end user authenticates, they see "Your \[App Name] is requesting access...".
The below video shows how an Embedded integration will look when Custom OAuth is enabled.
## Getting Started with Custom OAuth
On every OAuth block you'll see a configuration in the integration Settings as seen below in the Salesforce CRM example.

To configure Custom OAuth, you'll need to provide Alloy Embedded with the necessary information – each app may vary slightly but generally most apps follow the [OAuth standard](https://oauth.net/2/) .
Custom OAuth will prompt you to enter the required fields. In the case of Salesforce CRM those are as follows:
* **Client Id**: The client Id of your Salesforce CRM app
* **Client Secret**: The client secret for your Salesforce CRM app
* **Scope**: The scopes (provided by Alloy) Alloy Embedded needs to collect. You may need to request these scopes in your Salesforce CRM OAuth app configuration.
* **Redirect URL**: The URL (provided by Alloy) where the OAuth app should redirect to. You may need to specify this in your Salesforce CRM OAuth app configuration. This tells Salesforce how to properly handle the redirection request after the OAuth handshake is completed and customers will be routed back to your site upon redirection.


Failure to provide the right scopes may result in errors during workflow executions.
By default, we request all the scopes we need to support *every API endpoint* supported by Alloy Embedded. If you want to limit that or only need access to a select few, you can configure that via the scope checkboxes as seen below. Note that failure to supply the right scopes may result in workflows erroring. Generally, we recommend ensuring your app has full access to all required scopes.

## Wrapping Up
In this tutorial, we looked at how to set up our own client Id and client secret to whitelabel the end user's OAuth experience. With Custom OAuth, users will see your company's branding on OAuth-enabled apps.
# Handling Output Data
Source: https://docs.runalloy.com/embedded/handling-output-data
## Overview
In the Embedded workflow builder, each block has output data that enables variables to be mapped from one block another. Output data is sourced one of three ways:
1. By making a call to the API you're interacting with an pulling live data from your account.
2. Using a payload obtained from the third-party's documentation site when the required resource is inaccessible (ex. the data doesn't exist in your account or the API doesn't make the data available via API).
3. Using a custom payload defined by you
Below, we'll walk through an example of each and show you what you can do with your output data.
## Understanding output data sources
Most of the time, you'll be interacting with sample data that's sourced from the credentials that you've added to Embedded. When that's not possible, Embedded uses a payload that's defined by the third-party app's documentation.
Even then, data from your account may not always be available. For example, you may not have access to an account with valid credentials, the specified resource may not yet exist in the credential, or the API may not provide access to the get the data structure of the resource programmatically.
However, even with options to select data sourced from your account or the app documentation, there may still be instances in which they do not accurately represent data that you may encounter in production executions. If this is the case, you can edit the output data exactly to your requirements.

## How to use output data in subsequent blocks
Output data from one block defines the variable selector of subsequent blocks. You are able to select variables at any level of the JSON or the output over in it's entirety.
# Headless Mode
Source: https://docs.runalloy.com/embedded/headless-mode
## Overview
Headless Mode allows you to build a fully custom interface without displaying any Alloy-branded components. This gives you complete control over the end-to-end user experience while leveraging our integration infrastructure behind the scenes.
## Getting Started
A typical Headless Mode user flow looks like this:
Let's explore each step in detail.
### Create a User
First, create a user by calling the `/users` endpoint:
```bash cURL theme={null}
curl --request POST \
--url https://embedded.runalloy.com/users \
--header 'Authorization: YOUR_BEARER_KEY' \
--header 'accept: application/json'
```
**Sample Response**
```json JSON theme={null}
{
"userId": "6634f9aa6adb117b4c47d8ab"
}
```
This returns a `userId` for the newly created user.
### List Integrations
To [list your available integrations](/reference/embedded/list-integrations), use any `userId` or `username` you've previously created:
```bash cURL theme={null}
curl --request GET \
--url https://embedded.runalloy.com/integrations?userId=ANY_USER_ID \
--header 'Authorization: YOUR_BEARER_KEY' \
--header 'accept: application/json'
```
### Display and Collect Auth Fields
Once your user selects an integration to connect, you'll need to display the authentication fields required by that third-party app. To determine which fields to show, make a request to the `metadata/credentials` endpoint. Replace `APP_NAME` with the name of the selected integration (e.g., Shopify):
```bash cURL" theme={null}
curl --request GET \
--url https://embedded.runalloy.com/metadata/credentials/APP_NAME \
--header 'Authorization: YOUR_BEARER_KEY' \
--header 'accept: application/json'
```
The `APP_NAME` can be found in the response from the [List integrations](/embedded/headless-mode#list-integrations) endpoint.
**Sample Response**
Here's a sample response for Shopify:
```json JSON" theme={null}
{
"data": {
"name": "shopify",
"icon": "https://cdn.runalloy.com/icons/shopify.png",
"isOauth": true,
"properties": [
{
"name": "shopSubdomain",
"displayName": "Shop Subdomain",
"description": "Enter your store subdomain. If your store domain is example.myshopify.com, the subdomain would be example."
}
]
}
}
```
From this response, you can see that Shopify uses OAuth authentication (`isOauth: true`) and requires one auth field: **Shop subdomain**. Display this field in your interface:

Once the user enters the required auth field(s), proceed to obtain a `credentialId`.
## Getting a CredentialId
A `credentialId` allows your app to perform actions like reading and writing data on behalf of the end-user once authenticated.
Typically, authentication is handled via the [Alloy Modal](/embedded/modal/modal-sdk). But to leverage a truly headless experience, you can ditch the modal completely. This is where our programmatic credential endpoints come in.
First, you'll need to determine if the third-party app uses OAuth or non-OAuth for authentication. See the [Display and Collect Auth fields](/embedded/headless-mode#display-and-collect-auth-fields) section for more.
### Custom OAuth (Optional)
When using Headless Mode, users will see the **Alloy Automation is requesting access to...** screen on the third-party app. To display your branding instead, you'll need approval from the third-party app. Read [this tutorial](/embedded/handling-custom-oauth) to learn more about using Custom OAuth with Headless Mode.
### Getting a CredentialId for OAuth Apps
If the third-party app uses OAuth, follow these steps:
## What is an Integration?
An integration is a combination of workflows centered around a Third Party App. For example, you could build a Shopify integration that has two workflows:
* Workflow #1 is triggered whenever an end user places an order in your platform and then creates an order record in Shopify.
* Workflow #2 listens for new order creations in Shopify and streams them to your data warehouse
## Breaking it Down
The below illustration details the flow of data within these two workflows.
This integration sends data to your server and also receives data from your application:
* In Workflow #1, your application is the *Event* and Shopify is the *Destination*.
* In Workflow #2, Shopify is the *Event* and your application is the *Destination*.
We assume you're [streaming data](/connectors/utility/data-streaming) to your application via the Data Stream block.
This flow works in many scenarios but you might not always want to ingest data in your server. In many instances, it makes more sense to send incoming data directly to a data warehouse (such as Snowflake, BigQuery, etc). The below illustration shows how you could configure such a flow.
Being able to send outgoing data to a Third Party App and also receive events from the same app is known as a **bi-directional data sync**.
For more information about how to stream data to a destination, [see this article](/connectors/utility/data-streaming#streaming-data-to-a-warehouse).
## Wrapping Up
In this tutorial, we learned how to build an integration. Integrations are a collection of workflows that send outgoing data to a Third Party App and can also listen in for incoming data.
We call this two way flow a bi-direction data sync. With Alloy Embedded, you can build powerful integrations in minutes.
# Building Integrations With Custom Event and Custom Action
Source: https://docs.runalloy.com/embedded/knowledge-articles/building-integrations-with-custom-event-and-custom-action
## Overview
Custom action allows ISVs to support endpoints that Alloy may not support out of the box. Learn more about
## Setting up your First Custom Event
## Creating Users
Each user on your platform that uses Embedded should be tied to a corresponding user in Embedded. Let's take an example. Assume your company, ACME Co, has purchased Embedded and is building a Slack integration. A new user called "Joe Smoe [joe@example.com](mailto:joe@example.com)" signs up for your platform. In order to enable Embedded for Joe, you'll need to create a user via the Embedded API. The Create User endpoint takes an email address as input to easily identify the user in question. For any historical users you have on your platform prior to ACME Co using Embedded, you'll want to create the relevant Embedded users too.
Creating a new user in Embedded returns a unique username. We recommend storing this username somewhere in your database; you can however reference it anytime you like by using our Get User or List Users endpoints. As mentioned above, a best practice when using Embedded would be to create users for all old and new merchants. While accounts can be created on-demand, proactive creation allows you to catch email conflicts and speed up the merchant flow upon the first integration installation.
## Managing User Tokens
Once the user is created, in order to render the Embedded modal, you'll want to [generate a User Token](https://alloyautomation.readme.io/reference/get-user-token). The User Token is a JSON Web Token (JWT) that is required to securely render the Embedded Modal in your application and must be regenerated every time you want to show the modal.
### When to use
Use the Modal SDK if you present the Embedded iPaaS modal inside your product. It is not required for Headless or Alloy Link flows.
**What it provides**
* Render the Embedded iPaaS modal for integrations and workflows
* Authenticate the end user with `Alloy.setToken(...)`
* Install, edit, and update workflows: `Alloy.install`, `Alloy.edit`, `Alloy.update`
* Query installed integrations and workflows: `Alloy.getIntegrations`, `Alloy.getWorkflows`
* Activate or deactivate workflows: `Alloy.reactivate`, `Alloy.deactivate`
### Installing the Modal SDK
Install via npm or yarn:
```sh theme={null}
npm install alloy-frontend
# or
yarn add alloy-frontend
```
Or include via script tag:
```html theme={null}
```
Set your user token before calling SDK methods:
```js theme={null}
Alloy.setToken("
## Creating users
Create a user in Embedded iPaaS for each account in your app that needs integrations. For example, when a new user signs up in your product, call the **Create User** endpoint with their email. Store the returned `username` in your database. You can retrieve users later via **Get User** or **List Users**.
Proactive creation for existing accounts is recommended to surface any email conflicts early and to speed up the first-time integration flow.
* API reference: [Create a User](https://alloyautomation.readme.io/reference/create-a-user)
## Managing user tokens
To render the Embedded iPaaS modal, generate a **User Token** (JWT) for the target user each time you show the modal. Tokens expire after a maximum of 30 minutes.
* API reference: [Get User Token](https://alloyautomation.readme.io/reference/get-user-token)
## Overview
In this guide, we'll walk through how to get started building integrations with Alloy Embedded. Alloy Embedded is the easiest and fastest way to go live with not just one but hundreds of pre-built, maintained, and powerful integrations.
Offering your users integrations with Third Party Apps (3PA) has increasingly become an essential part of any successful SaaS product. But building and maintaining dozens of robust integrations require a sizable time and financial commitment that ultimately takes time away from your product roadmap.
Enter Alloy Embedded.
Alloy Embedded is an Embedded iPaaS product designed to streamline building native integration experiences. Let us handle the complexity of managing integrations – just implement our SDK once and build integrations with ease.
In this Quick Start guide, you'll learn how to create comprehensive integrations with the Alloy Embedded platform. We’ll cover the following topics:
* Key concepts
* How to build an integration
* How to add Alloy Embedded to your application
* Going live
Prior to reading this guide, we strongly recommend reviewing our [Terminology](/embedded/terminology) page as we'll be mentioning these terms throughout this guide.
Grab a cup of coffee and let’s dive in!
## Key Concepts
Before we begin, let's align on a handful of key terms:
| Term | Definition |
| :----------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| ISV | We refer to you as the Independent Software Vendor (ISV). The ISV determines what integrations to build and show in their application |
| End User | We refer to the users/clients of your application as users or end users. Users authenticate their credentials and choose which integrations to install. Users interact with your platform and connect their integrations using the Alloy Embedded modal behind the scenes. |
| Integrations | An integration is a combination of workflows centered around a Third Party Application. For example, you could build a Shopify integration with three workflows: (a) workflow #1 sends *order* data to your data warehouse every time a Shopify order is placed, (b) workflow #2 syncs *customer* data to your data warehouse, and (c) workflow #3 tags a customer in Shopify when a user clicks a button on your site. |
| Workflows | Workflows define exactly what should happen when any given event occurs. A workflow consists of an event (also known as a "trigger") and a destination (also known as an "action block"). An event initiates the workflow. A destination defines where the data from the event should be routed to (e.g. assume you built a workflow that creates a new contact in NetSuite every time a customer signs up in your app. In this scenario, the event is triggered whenever a customer signs up in your application and the destination is NetSuite). |
| Installation | You build workflows and integrations using our visual interface, known as the Alloy Workflow Builder. Every time an end user installs a workflow, they create a copy of the template you've built. Each user-specific copy of the template is called an installation. You can think of a workflow like a class in programming. The template you build in the Alloy Workflow Builder defines the general structure of your flow. When your end user installs that workflow, they create an instance (i.e. an installation) of that workflow specific to them. |
| Alloy Modal | Often referred to as just the “modal”, the Alloy Modal is part of our [Frontend JavaScript SDK](/embedded/frontend-javascript-sdk) and is used to collect the details from users needed to setup and configure an integration (example below). |
## Integration Structure
Before we build our first integration, let's take a moment to plan it. Assume you're a software engineer at AcmeCo were given the following product requirements:
We'll need to build two workflows to support this use case:
* **Workflow #1**: When a new order is created in BigCommerce, create a new record in AcmeCo
* **Workflow #2**: When a fulfillment status is updated in AcmeCo, update the order status in BigCommerce
## Use Case Overview
When developing features for small businesses, it's crucial to quickly assess their financial position. Implementing workflows to retrieve a merchant's accounts payable data can help you automate services such as cash advances and business loans.
### Define the Payload
To get started, create a workflow with a Custom Event and select the Accounting System of your choosing. You will need to define the schema you'll be sending over to Alloy in your Custom Event payload.
Next, select the Accounting System of choice. For our demo, we'll use Quickbooks.
### Lookup a Vendor by Email
Next, we'll check if the Vendor exists in the Accounting System. To do so, we can look them up by email. If the Vendor exists, we'll use the Vendor Id when we create a Bill.
### Add a conditional
Next, we'll introduce a conditional that checks if the Vendor exists. If the Vendor exists, we'll create a Bil. Ilf the Vendor does not exist, we'll first create a Vendor record and then Create the Bill after the Vendor record has been saved. We need to associate Vendors with Bills.
### Create a Customer
If the Customer does not already exist within the Accounting System, we'll need to first create a Customer record. Creating a customer is necessary in order to properly associate a Customer to an Invoice record. Select the **Create Customer** action and map the relevant fields accordingly.
### Create Bill
Now that we've created a Vendor, we can associate the Vendor with a Bill and create the Bill accordingly.
## Wrapping Up
By now, your workflow should look like the below. To recap, let's walk through how this flow functions:
## Use Case Overview
When developing features for small businesses, it's crucial to quickly assess their financial position. Implementing workflows to retrieve a merchant's accounts receivable data can help you automate services such as cash advances and business loans.
### Define the Payload
To get started, create a workflow with a Custom Event and select the Accounting System of your choosing. You will need to define the schema you'll be sending over to Alloy in your Custom Event payload.
Next, select the Accounting System of choice. For our demo, we'll use Quickbooks.
### Lookup a Customer by Email
Next, we'll check if the Customer exists in the Accounting System. To do so, we can look them up by email. If the customer exists, we'll use the Customer Id when we create the Invoice.
### Add a conditional
Next, we'll introduce a conditional that checks if the Customer exists. If the Customer exists, we'll create an Invoice. If the Customer does not exist, we'll first create a Customer record and then Create the Invoice after the Customer record has been saved.

### Create a Customer
If the Customer does not already exist within the Accounting System, we'll need to first create a Customer record. Creating a customer is necessary in order to properly associate a Customer to an Invoice record. Select the **Create Customer** action and map the relevant fields accordingly.
### Create Invoice
Now that we've created a Customer, we can associate the Customer with an Invoice and create the Invoice accordingly. You'll be prompted to map various data fields like Country, Customer Reference, and Line Items. You can find a more complete example in the Workflow Builder.
## Wrapping Up
By now, your workflow should look like the below. To recap, let's walk through how this flow functions:
## Use Case Overview
Let's assume you are building a tool that gives businesses visibility into their financial health using data from their balance sheet. To successfully build and launch this tool, you'll need a way for these businesses to quickly and securely grant you access to their accounting data. This is where Alloy comes in! With Alloy, A business can safely and securely grant access to their financial information to software vendors like you.
In this guide, we'll cover how to retrieve the data needed to help a Business understand their balance sheet better.
### Balance Sheet Data
Learn more about building a [balance sheet](/embedded/use-cases/accounting-and-erps/underwriting#balance-sheet-data) workflow with Alloy.
## Wrapping up
Alloy provides the tools to help you build powerful accounting workflows, helping your end users gain better visibility into their financial data.
# Cash Flow Analysis
Source: https://docs.runalloy.com/embedded/use-cases/accounting-and-erps/cash-flow-analysis
In this guide, we'll look at how to get all of the necessary data you need to perform a Cash flow analysis on a business.
## Use Case Overview
A cash flow analysis is essential when analyzing a business's liquidity position, forecasting a business' future cash flow, or helping a company make better operational decisions.
With Alloy, you can quickly access the real-time financial data you need to make data-driven decisions for a business. To conduct a thorough cash flow analysis, you'll need to gather data such as bank transactions, accounts receivable (invoices), accounts payable (bills), and payments, among other financial details. In this guide, we'll look at how to retrieve this essential data when analyzing a business.
### Bank Transactions
To start, create a workflow using the **On Installation Trigger**.
## Use Case Overview
When preparing a compliance report, you need several pieces of accounting data to ensure that all financial activities are reported accurately.
Assume you are building compliance software for businesses. Compliance reporting requires accounting data such as Profit and Loss statements, Balance sheets, Cash flow statements, Accounts payable, Accounts receivable, payroll data, tax data, and more.
In this guide, we'll cover how to retrieve the data needed to help prepare a compliance report for a business with Alloy.
### General Ledger Report
To start, create a workflow using the **On Installation Trigger**.
## Use Case Overview
As a Fintech, Neobank, or expense card provider, when building an expense management app or feature, you need access to a company's recorded expenses. With Alloy, you can build integrations with any accounting software businesses use today, providing a consolidated view of a business' expenses.
Using Alloy's accounting integrations you can categorize expenses and perform in-depth analysis, enabling businesses to gain actionable insights into their spend. To achieve this, you'll need access to data like accounts payable (bills) and payments.
### Accounts Payable (Bills)
Learn more about building an [Accounts payable](/embedded/use-cases/accounting-and-erps/accounts-payable) workflow.
### Payments
Learn more about building a [payments](/embedded/use-cases/accounting-and-erps/underwriting#payments) workflow.
## Wrapping up
When building an expense management feature, you can save time by using Alloy to quickly integrate with the accounting software your end users use. With these integrations, you can pull the necessary information to help businesses manage their expenses effectively.
# Tax Reporting
Source: https://docs.runalloy.com/embedded/use-cases/accounting-and-erps/tax-reporting
In this guide, we'll look at how to get the necessary data you need to prepare a comprehensive tax report.
## Use Case Overview
When preparing a tax report, you need to gather several accounting data to make sure that all taxable income, deductible expenses, and any other relevant financial activities are reported accurately.
Let's assume you are building tax reporting software for businesses. You'll need access to a business' books to accurately help them calculate, prepare, and report their taxes. Tax reporting requires accounting data such as Profit and Loss, expenses, assets, and more.
In this guide, we'll cover how to retrieve the data needed for a business to accurately report their taxes using Alloy.
### Profit and Loss
To get a business' income data, you'll need access to its profit and loss statement.
To start, create a workflow using the **On Installation Trigger**.
## Use Case Overview
Picture this: you're a lending business and want to underwrite a \$50,000 loan for a merchant. How do you validate the merchant should be eligible for this loan? Traditionally, you *could* look at bank statements manually but clearly this isn't ideal.
Using Alloy, you can easily grab realtime financial data to get the most accurate financial picture when underwriting.
### Balance Sheet Data
To get started, create a workflow with the On Installation Trigger and select the Accounting System of your choosing. The On Installation Trigger tells Alloy to only run this workflow the initial time an end user connects. If you need to run the workflow multiple times, you can use a Custom Event or a Scheduled Trigger to run at specific intervals.
Next, select the Accounting System of choice. For our demo, we'll use Xero. You can see a snippet of the financial data available below:

### Obtaining Balance Sheet
To obtain Balance Sheet data, select the Retrieve Balance Sheet action. We can then stream the Balance Sheet data back to your application with the Data Stream connector.
Your workflow should look like the below.

### Trial Balance
You can use Alloy to retrieve a user's Trial Balance. Select the Trial Balance action within Alloy to retrieve and then stream this data back to your application.

### Payments
Use Alloy to retrieve all payments in your Accounting System/ERP. The workflow below makes it easy to configure this use case.

### Profit & Loss
You can also retrieve Profit and Loss data via Alloy's accounting integrations as seen below.

## Wrapping Up
You can use Alloy to build powerful workflows that retrieve financial data including P\&L, Balance Sheet, Trial Balance, Payments, etc. You also also subscribe to realtime events to get notified each time a record is updated or created in a 3rd party app (i.e. every time a new Sales Order is created, notify me).
# Catalog Sync
Source: https://docs.runalloy.com/embedded/use-cases/ecommerce/catalog-sync
In this guide, we'll take a look at how to use Alloy to configure Catalog Sync workflows with popular e-commerce applications
## Use Case Overview
Let's assume you're building an app that needs to sync catalog data from an e-commerce system such as Shopify into your platform. You need to first obtain a historical listing of all the relevant products and then subscribe to realtime events each and every time an product is created or updated.
To do this, we'll build a few workflows. Our first workflow will grab the historical list of all available products. Our second workflow will set up realtime event forwarding for events you will send to Alloy and pass them along to your commerce system. Lastly, our third and final workflow will subscribe to all catalog updates so you can be alerted each and every time an update occurs on a product.
Time to dive in!
### Syncing Historical Catalog
Create a new workflow. For the trigger, we'll select "On Installation" as our trigger. This trigger tells Alloy to only run this workflow once, upon the user's initial install.
Next, add a e-commerce connector. For our demo, we'll use Shopify but you can easily use others like BigCommerce, Adobe Magento, WooCommerce, etc. Select the list all products action.
Lastly, add a Stream Data connector. This connector will tell Alloy where to send all the catalog records to. Specify a destination URL of your choosing. You can see an example of this workflow below.

### Realtime Catalog Alerts
Next, let's build another workflow that allows us to create a product in our e-commerce system. For this workflow, we'll choose a [Custom Event](/embedded/custom-events) Trigger as our starting point. This will allow Alloy to map the data and take action in our commerce system.
Next, add a e-commerce connector. Select the create a product action. This is where we will map our dynamic values from the event we will send to Alloy into the Shopify inputs.

### Realtime Catalog Updates
Lastly, let's create a workflow that alerts us each time a product is updated in our e=commerce system. For this workflow, we'll choose the Shopify Trigger as our starting point and subscribe to the Product Updated event.
Add a Stream Data connector to send over the product payload in real time to your application. You can see an example of this workflow below.

## Wrapping Up
As you can see, it's easy to create workflows that subscribe to both historical and realtime catalog data in e-commerce systems. Let's take a look at what we covered in this tutorial:
In this guide, we'll take a look at how to use Alloy to configure Order Sync workflows with popular e-commerce applications
## Use Case Overview
Let's assume you're building an app that needs to sync order data from an e-commerce system such as Shopify into your platform. You need to first obtain a historical listing of all the relevant orders and then subscribe to realtime events each and every time an order is placed.
To do this, we'll build a few workflows. Our first workflow will grab the historical list of all available orders. Our second workflow will set up realtime event forwarding to subscribe us to incoming orders placed and pass them along to your application. Lastly, our third and final workflow will subscribe to all order updates so you can be alerted each and every time an update (e.g. a status change) occurs on an order.
Let's dive in!
### Syncing Historical Orders
Create a new workflow. For the trigger, we'll select "On Installation" as our trigger. This trigger tells Alloy to only run this workflow once, upon the user's initial install.
Next, add an e-commerce connector. For our demo, we'll use Shopify but you can easily use others like BigCommerce, Adobe Magento, WooCommerce, etc. Select the list all orders action.
Lastly, add a [Stream Data](/connectors/utility/data-streaming) connector. This connector will tell Alloy where to send all the order records to. Specify a destination URL of your choosing. You can see an example of this workflow below.

### Realtime Order Alerts
Next, let's build another workflow that allows us to create an order in our e-commerce system. For this workflow, we'll choose a [Custom Event](/embedded/custom-events) Trigger as our starting point. This will allow Alloy to map the data and take action in our commerce system.
Next, add a e-commerce connector. Select the create an order action. This is where we will map our dynamic values from the event we will send to Alloy into the Shopify inputs.

### Realtime Order Updates
Lastly, let's create a workflow that alerts us each time an order is updated in our e-commerce system. This is helpful to understand changes in the order state (i.e. if the status changed). For this workflow, we'll choose the Shopify Trigger as our starting point and subscribe to the Order Updated event.
Add a Stream Data connector to send over the order payload in real time to your application. You can see an example of this workflow below.

## Wrapping Up
As you can see, it's easy to create workflows that subscribe to both historical and realtime order data in e-commerce systems. Let's take a look at what we covered in this tutorial:
## Use Case Overview
As a Fintech or Neobank business, you recognize that deciding who to advance credit is never an easy decision. Having access to real-time data can help take the hassle out of the process. Leveraging integrations by Alloy can provide you with a competitive edge by significantly reducing the turnaround time for extending same-day credit to a business.
### Accessing Real-time Balance
You can access a Business' real-time balance in Stripe using Alloy's Stripe connector.
To start, create a workflow using the **On Installation Trigger**.
## Use Case Overview
For businesses handling tens of thousands of transactions daily, managing customer disputes can be a pain. Alloy helps software vendors solve this problem for their merchants by providing integrations with payment providers like Square, Stripe, and Recharge, enabling efficient dispute management.
### Sending alerts when a Dispute is raised
Let's create a workflow to notify our app whenever a dispute is raised in a merchant's account on our platform.
Navigate to the Alloy workflow builder. Click New Integration and search for Stripe.
On the Workflows screen, click New Workflow.
Next, select a trigger for the workflow. Search for Stripe Trigger in the list of connectors. Drag the Stripe Trigger into the Workflow UI and search for *Trigger workflow when issuing dispute created*. Add this action to the workflow builder.

Next, use the Stream Data connector to stream the result from the Stripe trigger connector to your servers.
Once you receive this notification within your app, you can choose how to notify the affected merchant; via an in-app notification, E-mail, or SMS.
Your completed workflow should look like below:

## Wrapping Up
Alloy's payments connector allows you to build dispute management features into your app using a simple workflow editor.
# Payouts
Source: https://docs.runalloy.com/embedded/use-cases/payments/payouts
In this guide, you'll learn how to get real-time notifications when a payout is made within a user's account.
## Use Case Overview
If you're building features for reconciliation, cash flow management, or financial reporting in your app, knowing when a payout is initiated in your merchant's account is essential for maintaining accurate financial data.
With Alloy, you can receive real-time alerts allowing your app to react to changes in your merchant's accounts.
### Getting a Payout Alert
Let's build a simple workflow that sends a notification to your server when a payout is initiated in your merchant's account.
Navigate to the Alloy workflow builder. Click New Integration and search for Stripe.
On the Workflows screen, click New Workflow.
Next, select a trigger for the workflow. Search for Stripe Trigger in the list of connectors. Drag the Stripe Trigger into the Workflow UI and select the *Trigger workflow when payout created* action. Add this action to your workflow.
Next, use the Stream Data connector to stream the result from the Stripe trigger connector to your servers.
Your completed workflow should look like this:

You can use this information to update a user's financial records with you and also to alert them.
## Wrapping Up
Alloy provides integrations with payment systems like Stripe, Square, and Recharge, enabling you to gain real-time access to transaction data when a critical event like Payout creation occurs.
# Refunds
Source: https://docs.runalloy.com/embedded/use-cases/payments/refund
In this guide, you'll learn how to get real-time notifications when a refund is initiated in a merchant's account.
## Use Case Overview
If you're building features for reconciliation, cash flow management, or financial reporting in your app, knowing when a refund is initiated in your merchant's account is essential for maintaining accurate financial data.
With Alloy, you can quickly integrate with a merchant's payment platforms to receive real-time alerts when events like refund initiations occur.
### Getting a Refund Alert
Let's build a simple workflow that sends a notification to your server when a refund has been initiated in your merchant's account by a customer.
Navigate to the Alloy workflow builder. Click New Integration and search for Stripe.
On the Workflows screen, click New Workflow.
Next, select a trigger for the workflow. Search for Stripe Trigger in the list of connectors. Drag the Stripe Trigger into the Workflow UI and select the *Trigger workflow when new refund* action. Add this action to your workflow.
Next, use the Stream Data connector to stream the result from the Stripe trigger connector to your servers.
Your completed workflow should look like this:

## Wrapping Up
Alloy provides integrations with payment systems like Stripe, Square, and Recharge, enabling you to gain real-time access to transaction data when a critical event like refund initiation occurs.
# Subscriptions
Source: https://docs.runalloy.com/embedded/use-cases/payments/subscriptions
In this guide, you'll learn how to get real-time alerts when a subscription is created or updated within your merchant's accounts.
## Use Case Overview
If you're building a CRM or billing and invoicing software for merchants, you need to know when a new subscription has been created or updated in the third-party software the merchant uses.
With Alloy, you can receive real-time alerts allowing your app to react to changes in subscription data within a merchant's account.
### Receiving Subscription Alerts
Let's build a simple workflow that notifies your server when a subscription is created or updated within a merchant's account.
Navigate to the Alloy workflow builder. Click New Integration and search for Stripe.
On the Workflows screen, click New Workflow.
Next, select a trigger for the workflow. Search for Stripe Trigger in the list of connectors. Drag the Stripe Trigger into the Workflow UI and select the *Trigger workflow when new subscription* action. Add this action to your workflow.
Next, use the Stream Data connector to stream the result from the Stripe trigger connector to your Webhook server.
Your completed workflow should look like this:

## Wrapping Up
Alloy provides integrations with payment systems like Stripe, Square, and Recharge, allowing you to gain real-time access to events like Subscriptions created or updated.
# Automated Lead Routing
Source: https://docs.runalloy.com/embedded/use-cases/sales-and-crm/automated-lead-routing
Alloy simplifies the process of setting up lead routing from any third-party system directly into your app.
You can do so in three steps:
Let's get started!
Alloy Automation is the all-in-one integration platform designed for SaaS and AI.
We offer three ways to build enterprise-grade workflows and connectivity.
The Connectivity API embeds native integrations via a single endpoint. Embedded turns integration requests into marketplace offerings, enabling fast builds with minimal engineering. MCP provides AI agents secure, remote-hosted access to 1000+ tools with built-in context, permissioning, and authentication.
Drag-and-drop orchestration tool for creating integrations and mapping data without engineering lift. It's ideal for teams shipping embedded iPaaS experiences quickly.
Real-time, native integration UIs with a single API, including hosted config and auth flows. It's ideal for teams embedding integrations directly into their product with minimal setup.
Make sure you check off the**Configurable by user** setting which will expose this variable to your end-users when they install. You can create your own label and help text to better instruct end-users on how to utilize this field.
### 2. Choose a Workflow Trigger
Here, we'll assume that the orders are originating in your platform, as the ISV, or a platform that you manage on behalf of your customers. As order fulfillment is a fairly time-sensitive process we suggest chooseing a real-time or near-real-time method for syncing order data from your systems into your e-commerce platform of choice:
* [Custom Event](https://docs.runalloy.com/embedded/custom-events#custom-events) - Invoked in your systems and can be used to pass along order data as individual orders are created
* **Recurring Sync** - Can be used to run the order syncing workflow on a recurring basis, should also be combined with a polling endpoint from which the workflow can pull bulk orders via [Custom API Call](https://docs.runalloy.com/embedded/custom-api-calls#custom-api-calls)
### 3. Send Order Data to Alloy
If using a Custom Event to send real-time order data from your systems, you can pass the entire order payload as part of the Custom Event schema. If you'll be polling a bulk order export endpoint on your REST API instead, you can pass along an array of order payloads.
### 6. Creating Line Items
Some E-Commerce connectors in Alloy will allow you to add line items directly within the 'Create Order' connector action. Other Connectors will require you to manually create line items\_after\_ the order is created, using a separate action. In this case you'll want to do the following:
* After the 'Create Order' action, add an [Iterate](https://docs.runalloy.com/embedded/iterate#iterate) node and pass in the 'line items' list from the original order payload as the**List to loop through** .
* Within each loop iteration, add a 'Create Order Line Item' action to capture each individual line item
* Pass the returned 'Order ID' from the 'Create Order' action into the**Order ID** field in the 'Create Order Line Item' action. This is how we associate line items created in a separate step, with the parent Order object
If you're able to create line items within the same action as creating an order, you can typically use**Dynamic List Mode** which allows you to pass an list directly into the action and Alloy will automatically iterate through all records in the list
## Video Walkthrough Library
*We've created video walkthroughs for the most common and complex integration scenarios. Choose a walkthrough below to build alongside our experts. We regularly add new videos, so check back for updates!*
In Shopify's GraphQL API, however, the return itself is a separate API request. You can see an example of that request below:
```
mutation CreateReturn($input: ReturnCreateInput!) {
returnCreate(return: $input) {
return {
id
status
returnLineItems {
id
quantity
}
}
userErrors {
field
message
}
}
}
```
### 6. Communicate the Refund to the Customer (Optional)