> For the complete documentation index, see [llms.txt](https://docs.thewalletcrew.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.thewalletcrew.io/connectors/pos/cegid/events-and-operations/business-notifications.md).

# Business notifications

Use Cegid Retail Y2 business notifications to refresh Apple Wallet and Google Wallet pass data after store activity.

Cegid can notify The Wallet Crew when relevant activity occurs. This refreshes wallet pass data promptly after a purchase or loyalty update. Notifications are optional and have important configuration constraints.

### The endpoint and the subscription are separate

This distinction explains most confusion about the feature, and it is not obvious from the interface.

The Wallet Crew always exposes a notification endpoint for a configured connection. It is authenticated, and it accepts notifications whenever Cegid is pointed at it, regardless of any setting in the administration console.

What the **Listen to business notification** setting does is manage the *subscription* inside Cegid. When enabled, The Wallet Crew registers itself as Cegid's notification subscriber using the credentials supplied alongside the toggle, and re-registers whenever the connector configuration is saved.

{% hint style="info" %}
A Cegid administrator who configures the subscription by hand in Cegid gets working notifications with the setting left off. Conversely, turning the setting on takes over a subscription that may belong to another system.
{% endhint %}

{% hint style="danger" %}
Cegid Retail Y2 supports a single business notification subscription. Enabling the setting disables any other. Where several systems need Cegid events, or where one Cegid database serves several Wallet Crew tenants, the subscription has to be shared rather than claimed, and the notifications distributed by whatever system holds it.
{% endhint %}

### What Cegid sends, and what happens

A notification carries identifiers, not content. The connector reads the affected record back from Cegid and refreshes the passes concerned.

| Event            | Raised when                                  | Effect                                                                 |
| ---------------- | -------------------------------------------- | ---------------------------------------------------------------------- |
| Customer created | A customer record is created in Cegid.       | Recorded; available to downstream automation.                          |
| Customer updated | A customer record changes.                   | Every pass linked to that customer is refreshed.                       |
| Receipt created  | A sale is completed or registered.           | The customer is resolved from the document and their passes refreshed. |
| Loyalty updated  | A loyalty card operation is recorded.        | The customer is resolved from the card and their passes refreshed.     |
| Other            | Any other Cegid event reaching the endpoint. | Recorded as a generic event. No pass refresh is triggered.             |

Receipts placed on hold are deliberately ignored, since the transaction is not complete.

{% hint style="warning" %}
Cegid emits a broader set of events than the connector acts on, and in busy implementations the generic category is the largest by volume, loyalty card line operations in particular. These are recorded but do not trigger a refresh. Where a brand expects a specific Cegid event to update a pass, it is worth confirming that the event is one of those handled above.
{% endhint %}

### Volume and duplicates

Notification traffic in an active retail estate is substantial, and each notification that results in a refresh generates Cegid reads of its own. Enabling notifications increases Cegid consumption, and the rate limit and cache settings in [Advanced configuration](/connectors/pos/cegid/setup-and-configuration/advanced-configuration.md) should be reviewed at the same time.

The endpoint does not deduplicate on the event identifier. A notification delivered more than once is processed more than once. Because processing consists of reading current state and refreshing a pass, the result is correct but the work is repeated.

### Retiring a configuration

A subscription registered in Cegid continues to send notifications until it is removed in Cegid. Decommissioning a Wallet Crew tenant does not remove it, and a subscription pointing at a retired tenant can continue delivering for a long time. Removing the subscription belongs in the decommissioning procedure described in [Operations runbooks](/connectors/pos/cegid/events-and-operations/operations-runbooks.md).

### FAQ

<details>

<summary><strong>Are business notifications required for passes to stay current?</strong></summary>

No. Passes refresh whenever they are rebuilt. Notifications make that happen promptly after activity in store instead of on the wallet platform's schedule.

</details>

<details>

<summary><strong>Notifications arrive but a pass does not change. Why?</strong></summary>

Most likely the event falls into the generic category, which is recorded but does not trigger a refresh. Confirming the event type Cegid is sending is the first step.

</details>

<details>

<summary><strong>Can two systems receive Cegid notifications?</strong></summary>

Not directly, because Cegid supports one subscription. A middleware holding the subscription and forwarding to both is the usual arrangement.

</details>


---

# 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://docs.thewalletcrew.io/connectors/pos/cegid/events-and-operations/business-notifications.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.