Firmhouse uses webhooks to allow you to communicate with different applications and share data smoothly. You can specify the information you want to send when each event happens using liquid templates. To set up a webhook on the Firmhouse Portal, check out this guide.
In this guide, we will use JSON payloads as it's the most common format for webhooks. However, you can use any other format that you can create a template for with Liquid, such as XML or YAML.
For each event group, there are specific variables that you can use in liquid templates.
Asset
You can use these variables in your templates for all asset events.
This event is triggered when an asset is assigned to a customer. You can check out this guide to see how you can assign an asset to a customer on Firmhouse Portal.
As shown in the example template above, you can use the liquid filter default: to set a default value for a field. You can also use any other filter supported by liquid. Check out the list here.
Contract term
You can use these variables in your templates for contract term events.
This event is triggered when a customer fails to pay for a billing cycle.
Example Template
As you can see in the example above, you can use tags like capture and for .. in to extract values from arrays easily. You can also use other tags supported by liquid. You can check the full list here.
Collection Case
You can use these variables in your templates for extra field events.
This event is triggered when the status of collection case is changed to closed.
Example Template
Collection Case Created
This event is triggered when a collection case is created for an invoice.
Example Template
Collection Case Open
This event is triggered when the status of collection case is changed to open.
Example Template
Extra field answer
If you added extra fields to your project, you can use these events to monitor when they are changed. Please check out this guide for instructions on setting up extra fields on Firmhouse Portal.
You can use these variables in your templates for extra field events.
This field contains all extra_fields you configured for the project. You can access each with `{{extra_field.field_name}}. The field names here are using snake_case. If you have an extra field with the name "Custom Message", you can access that with {{extra_field.custom_message}} tag.
Extra field answer updated
This event is triggered when one of the extra fields you defined for your project is updated on a subscription.
This event is triggered when a customer adds a new product to cart. This corresponds to createOrderedProduct mutation on our GraphQL API. Note that if the same product added more than one times, since it's only a quantity update, Ordered product updated event will be triggered.
This event is triggered when a product in cart is updated. This corresponds to updateOrderedProduct and updateOrderedProductQuantity mutations on our GraphQL API or when its automatically updated due to order state or shipment information change.
This event is triggered when a customer removed product from a cart. This corresponds to destroyOrderedProductmutation on our GraphQL API. ordered_product variable in this even corresponds to the product removed from cart
Example Template
Payment
You can use these variables in your templates for all payment events.
This event is triggered when a return order is cancelled.
Example Template
</div>
</details>
### Return order completed
This event is triggered when a return order is completed.
<details>
<summary>Example Template</summary>
<div data-gb-custom-block data-tag="code" data-lineNumbers='true'>
```liquid
{% raw %}
{%- capture return_order_products_string -%}
{%- for item in return_order.return_order_products -%}
{"quantity": {{item.quantity}}, "orderedProductId": "{{item.ordered_product.id}}", "productId": "{{item.ordered_product.product_id}}"};
{%- endfor -%}
{%- endcapture -%}
{% assign return_order_products = return_order_products_string | split:';' | join:"," %}
{% endraw %}
{
"event": "return_order_completed",
"subscription": {
"id": "{{subscription.id}}"
},
"returnOrder": {
"id": "{{return_order.id}}",
"reason": "{{return_order.reason}}",
"desiredReturnDate": "{{return_order.desired_return_date}}",
"status": "{{return_order.status}}",
"trackingCode": "{{return_order.tracking_code}}",
"trackingUrl": "{{return_order.tracking_url}}",
"externalStatus": "{{return_order.external_status}}",
"externalReferance": "{{return_order.external_referance}}",
"externalUrl": "{{return_order.external_url}}",
"returnLabelFileUrl": "{{return_order.return_label_file_url}}",
"returnedOn": "{{return_order.returned_on}}",
"returnOrderProducts": [{{return_order_products}}]
}
}
liq
Return order created
This event is triggered when a return order is created.
Example Template
</div>
</details>
***
## Subscription acceptance check
If you are using manual activation, you can use these events to track the status of acceptance checks. Please refer to [this guide](https://help.firmhouse.com/en/articles/3174058-set-up-manual-activation) for setting up manual activation and acceptance checks.
If you are using _**duplication**_, or _**Focum**_ acceptance check with "_**As part of the signup on submitting the signup form**_" option, the acceptance check will be created and validated during sign up. This corresponds to [`createSubscriptionFromCart`](../graphql-api/api-reference/mutations/create-subscription-from-cart.md) call.
For other types of acceptance checks, namely _**Manual**_, _**Identity Verification**_ or _**Focum**_ acceptance check with _**"As part of the signup on submitting the signup form."**_ option, the acceptance check will be created after customer completes the payment with pending status.
You can use these variables in your templates for all subscription acceptance check events.
* [subscription](../liquid/available-tags.md#subscription)
### Subscription acceptance check created
This event is triggered when an acceptance check is created for a subscription.
<details>
<summary>Example template</summary>
```liquid
{% raw %}
{%- capture acceptance_checks_string -%}
{%- for check in subscription.subscription_acceptance_checks -%}
{"name": "{{check.name}}", "id":"{{check.id}}","status": "{{check.status}}"};
{%- endfor -%}
{%- endcapture -%}
{% assign acceptance_checks = acceptance_checks_string | split:';' | join:"," %}
{% endraw %}
{
"event": "subscription_acceptance_check_created",
"subscription_acceptance_checks": [{{acceptance_checks}}],
"subscription": {
"id": "{{subscription.id}}"
}
}
Subscription acceptance check pending
This event is triggered when an acceptance check is created with pending status. It will only be triggered for these acceptance check types: Manual, Identity Verification, Focum acceptance check with "As part of the signup on submitting the signup form."
This event is triggered when the status of an acceptance check changes to accepted.
This will happen immediately on signup if the check passes when its created for these events: duplication, or Focum acceptance check with "As part of the signup on submitting the signup form" option. For other acceptance check types it will happen when the value is set to accepted.
This event is triggered when the status of an acceptance check changes to rejected.
The triggering timeline is similar to Subscription acceptance check accepted. The only difference is that it occurs when the checks fail or when it is manually set to rejected.
This event is triggered when a subscription is activated. Depending on your project settings this could happen either after successful initial payment or when the subscription is manually activated.
Example Template
Subscription Stopped
This event is triggered when a subscription is stopped. This happens automatically when the maximum commitment of a subscription is reached.