> 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/setup-and-configuration/advanced-configuration.md).
# Advanced configuration
Manage Cegid Retail Y2 rate limiting, caching, installation updates, and file-based connector settings.
Rate limiting and caching protect the Cegid environment from the volume a wallet programme generates. A small number of further settings are available only as configuration file entries. This page covers both, and how the two editing routes relate.
### Rate limiting
Cegid enforces a request ceiling over a rolling window across the whole environment. Exceeding it produces rejected requests, which affect every application sharing that environment, including the point-of-sale tills. The connector therefore applies its own limit first, deliberately below Cegid's, so that excess traffic is delayed on the Wallet Crew side rather than refused on the Cegid side.
Rate limiting is enabled by default. The limit to configure is the share of Cegid capacity allocated to The Wallet Crew, not the full plan ceiling, unless no other application uses the environment.
| Setting | Default | Meaning |
| ------------------------------- | ------- | ---------------------------------------------------------------------------------------------- |
| Enabled | On | Whether the limiter applies. |
| Permit limit | 4980 | Requests allowed per window. |
| Window *(file only)* | 300 s | The rolling window, matching Cegid's. |
| Retry after *(file only)* | 60 s | How long deferred work waits before retrying, when Cegid gives no guidance of its own. |
| Queue timeout *(file only)* | 0 s | How long a request waits for a permit. Zero means it is deferred immediately rather than held. |
| Queue retry delay *(file only)* | 1 s | Interval between permit attempts while queuing. |
{% hint style="warning" %}
**The limit is per Cegid host, not per tenant.** The limiter counts requests against the Cegid host being called. Where several Wallet Crew tenants point at the same Cegid environment, for example a group operating multiple brands from one Y2 instance, they share one budget. Each tenant's configured limit should reflect its share of the environment, not the whole of it, or the group will collectively exceed what Cegid allows.
{% endhint %}
When the limit is reached, work that can be deferred is rescheduled rather than failed, and retried after the interval Cegid indicates where it provides one. Changes to the limit apply from the next call; nothing needs redeploying.
#### Sizing the limit
Pass refresh traffic is easy to underestimate. Each refresh can call several Cegid services. Plan large refreshes against the same request budget used by store and third-party applications.
### Caching
Caching holds Cegid responses for a short period so that repeated identical reads, most often caused by wallet platforms polling the same pass, do not each become a Cegid call.
Four independent durations are available, for customer profiles, loyalty data, sales documents, and cash operations. All are expressed in seconds, and **all are off by default**: caching is opt-in, not something to be turned down from a default.
| Cache | Holds | Consideration |
| --------------- | ---------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| Customer | Customer profiles | Short durations are usually sufficient, because the traffic being suppressed is repeated reads within seconds. |
| Loyalty | Cards, programmes, point balances | The most visible to end-users: a balance that lags after a purchase is noticed. |
| Sale documents | Receipts and document lists | Historical data, so tolerant of longer durations. |
| Cash operations | Vouchers, gift cards, stored value | Balances change at the till; confirm freshness requirements before extending. |
Writes invalidate what they affect: updating a customer clears that customer's cached profile, and creating a loyalty card clears the cached card list. Durations of a few seconds already remove most duplicate traffic, because the pattern being suppressed is bursts rather than sustained reads.
### Updating the customer on pass installation
When enabled, which it is by default, installing or removing a pass writes the customer record back to Cegid. This is what allows a brand to see wallet adoption in its own CRM, provided the mapping writes an installation state into a Cegid field. The recipe for doing so is in [Customise the mapping](/connectors/pos/cegid/customer-data-and-loyalty/customise-the-mapping.md).
Where the brand does not record installation state in Cegid, the setting can be turned off to remove the corresponding traffic.
### Editing the configuration file directly
The connector's settings are stored as a YAML file in the tenant configuration store, and that file can be edited directly in the configuration workspace, which offers a file tree, schema validation, a problems panel, version history, and comparison between versions.
This is worth doing for the settings the connector page does not expose: the rate-limit window and retry intervals above, cache durations beyond a day, and binding a store to a named connection, which has no form equivalent.
{% hint style="success" %}
Mixing the two routes is safe. Saving from the configuration page preserves settings it does not itself display, so a value set in the file by hand is not lost when a subsequent edit is made through the form.
{% endhint %}
{% hint style="warning" %}
Values are not coerced. A value that does not match its expected type is not applied, and the intent is lost quietly — a boolean written with an unexpected capitalisation, for instance, is read as text rather than as a boolean. Where a file edit appears to have no effect, the value's form is the first thing to check.
{% endhint %}
### FAQ
What cache duration should be used?
Start with a few seconds on customer and loyalty data, which removes the bulk of duplicate polling traffic without a visible lag, and extend only if Cegid consumption remains high. Longer durations trade freshness for volume, and loyalty balances are where end-users notice.
Does a rate-limit change require a redeployment?
No. The new value applies from the next call to Cegid.
Where can the current configuration be reviewed as a whole?
The configuration workspace shows the file in full, with its change history, which is also the quickest way to see what changed and when following an unexpected change in behaviour.
---
# 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/setup-and-configuration/advanced-configuration.md?ask=&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.