> For the complete documentation index, see [llms.txt](https://agpt.co/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://agpt.co/docs/integrations/block-integrations/triggers-5.md).

# Rmfg Triggers

Trigger block that starts a graph on RMFG lifecycle events. Adding it to a graph registers a webhook endpoint with RMFG through the API; removing it deletes the endpoint again.

## RMFG Event Trigger

### What it is

Triggers when an RMFG design, quote, cart or order changes

### How it works

Select which events to subscribe to; the platform registers an endpoint at `/v1/webhook-endpoints` for exactly those events and stores the signing secret RMFG returns once, at creation. A connected RMFG account needs the `webhooks` permission from the approval page; an API key registers directly. Registration fails with a clear message when an event is unknown, when RMFG refuses (a 403 on a connected account says to reconnect and allow the webhooks permission), or when the response lacks an endpoint ID or a string signing secret, so no half-registered hook is ever kept. Removing the block deletes the endpoint again; an already-deleted endpoint is fine.

Each delivery is verified before it reaches the graph: `X-RMFG-Signature` must carry a `v1=` HMAC-SHA256 of `<X-RMFG-Timestamp>.<raw body>` under the stored secret, and a timestamp that is missing, unparseable or more than 300 seconds off is rejected with 403. A body that is not a JSON object or lacks `type` is rejected with 400, and an event type the block does not know triggers nothing. The event body is `{id, type, created_at, data}`; the block emits the type plus the data object's id, object, status and `status_url` (as empty strings when absent), so the next block can fetch the full resource with Get Design, Get DFM Report, Get Quote, Get Cart or Get Order.

### Inputs

| Input  | Description                        | Type   | Required |
| ------ | ---------------------------------- | ------ | -------- |
| events | Which RMFG events start this graph | Events | No       |

### Outputs

| Output         | Description                                                  | Type            |
| -------------- | ------------------------------------------------------------ | --------------- |
| error          | Error message if the operation failed                        | str             |
| payload        | The raw event RMFG delivered                                 | Dict\[str, Any] |
| event          | RMFG event type, e.g. order.status\_changed                  | str             |
| event\_id      | Unique ID of this event                                      | str             |
| resource\_id   | ID of the design, DFM report, quote, cart or order concerned | str             |
| resource\_type | design, dfm\_report, quote, cart or order                    | str             |
| status         | The resource's new status, when the event carries one        | str             |
| status\_url    | API URL of the resource, for fetching its full state         | str             |
| created\_at    | When RMFG emitted the event                                  | str             |

### Possible use case

**Fulfilment Feed**: Subscribe to `cart.checked_out` and `order.status_changed`, fetch the order, and post it to the fulfilment channel.

**Async Analysis**: Upload with waiting off and continue the graph when `design.ready` fires.

**Failure Alerts**: Route `design.failed` and `quote.failed` events to a person with the resource ID.

***


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://agpt.co/docs/integrations/block-integrations/triggers-5.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.