> 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/developer-reference/cegid-retail-y2-apis.md).

# Cegid Retail Y2 APIs

Review the Cegid Retail Y2 services used by The Wallet Crew and grant service-user access only for enabled wallet journeys.

This page lists the Cegid Retail Y2 services used by the connector and their purpose. It supports least-privilege service-user access for each enabled wallet journey.

For connector setup, see [Configure the Cegid Retail Y2 connector](/connectors/pos/cegid/setup-and-configuration/connect-with-cegid-retail-y2.md). For the customer field synchronisation these services carry, see [Cegid Retail Y2 fields mapping](/connectors/pos/cegid/customer-data-and-loyalty/cegid-retail-y2-fields-mapping.md).

### At a glance

The connector uses two integration patterns. Web service calls retrieve or update data on demand, and business notifications signal events that should trigger a refresh. Most services are SOAP; receipt generation and reference data are REST.

### Customer

Customer search, creation, and update, and the consent fields that travel with the record. Used by every wallet journey involving an identified customer.

**Operations:** search customer identifiers, add a new customer, update a customer.

### Loyalty

Card lifecycle and programme data. Two services are involved: the loyalty service for cards attached to a customer and individual card detail, and the loyalty engine for the programmes available at a store.

**Operations:** list a customer's cards, create a card, read a card, list programmes active for card creation at a store.

### Cash operations

Vouchers, gift cards, certificates, and deposits attached to a customer, and the available balance on an individual instrument.

**Operations:** list a customer's available instruments, read an instrument's available amount.

### Sale documents

Transaction records, for receipt and order journeys.

**Operations:** read by key, read by external reference, list document headers, create a document.

### Sales report

Receipt PDF generation, over REST rather than SOAP. Generation is a three-step sequence: request the document, poll until it is ready, download it.

### Reference data

Countries, regions, languages, and civilities, read over REST to populate enrolment form options with the values the brand's own Cegid database recognises.

### Stores and salespersons

The store catalogue, and salesperson lists for layouts displaying an advisor.

**Operations:** list stores, list salespersons.

### Business notification subscription

Management of the notification subscription described in [Business notifications](/connectors/pos/cegid/events-and-operations/business-notifications.md).

**Operations:** read active subscriptions, create, update, delete.

### Scheduled tasks

Listing and triggering Cegid scheduled tasks, for flows that need to run one as part of enrolment.

### Customer orders

Order data, for click-and-collect and similar journeys.

{% hint style="info" %}
Only the services supporting the journeys in scope need to be granted. A programme covering enrolment and loyalty display, with no receipt journey, does not require sale documents, sales report, or customer orders.
{% endhint %}

### FAQ

<details>

<summary><strong>Does the connector rely only on notifications?</strong></summary>

No. The connector uses direct web service calls to read and write data, and business notifications only to react to events in near real time.

</details>

<details>

<summary><strong>Which service generates receipt PDFs?</strong></summary>

The sales report service generates the PDF. The sale document service is used separately to retrieve document data and document lists.

</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/developer-reference/cegid-retail-y2-apis.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.
