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.

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.

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.

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.

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.

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.

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.