> ## Documentation Index
> Fetch the complete documentation index at: https://integration.delogue.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Read a style's contacts and supplier
> Retrieve the company and supplier contact people on a style, the supplier sub-resource, and the org-wide contact list for export or ERP sync.
**When to use this.** Every style carries a company (designer-side) contact person and, once a
supplier is assigned, a supplier contact person and the supplier's country. Use these endpoints
to read those details for a single style, to read the supplier sub-resource on its own, or to
pull the whole organisation's contact rows in one paginated list for an export or ERP sync. This
surface is read-only — contacts and the supplier are set through the style update flow, not here.
## The workflow
The contacts and supplier on a style are resolved from the style's own foreign keys, so there is
no separate record to create. The usual path is to look up one style's contacts, drill into the
supplier, or sweep the whole organisation for an export.
`GET /api/styles/{styleId}/contacts` returns the company contact, supplier contact, and
supplier country for a single style.
`GET /api/styles/{styleId}/supplier` returns just the supplier — name, custom id, country, and
contact person. It returns a `200` with a null payload when the style has no supplier.
`GET /api/style-contacts` lists one contact row per style across the organisation, filterable
by brand, season, supplier country, or contact person — built for export and ERP sync.
```mermaid theme={"dark"}
sequenceDiagram
participant D as Designer
participant API as Delogue API
D->>API: GET /api/styles/{styleId}/contacts
API-->>D: company + supplier contact, supplier country
D->>API: GET /api/styles/{styleId}/supplier
API-->>D: supplier (or null)
D->>API: GET /api/style-contacts?brandId=... (export)
API-->>D: one contact row per style (paginated)
```
## Walkthrough
Read the contacts for a single style, then the supplier on its own, then the org-wide list. Each
sub-object is `null` when the matching foreign key on the style is unset — a style with no supplier
returns `null` for `supplierContact` and `supplierCountry`.
```bash cURL theme={"dark"}
curl "https://service.my.delogue.com/api/style-contacts" \
-H "Accept: application/json" \
-H "X-Auth-Token: Bearer YOUR_API_KEY"
```
```js JavaScript theme={"dark"}
const res = await fetch("https://service.my.delogue.com/api/style-contacts", {
method: "GET",
headers: {
"Accept": "application/json",
"X-Auth-Token": "Bearer YOUR_API_KEY",
},
});
const { data } = await res.json();
```
```json theme={"dark"}
{
"status": "success",
"code": "ok",
"data": [
{
"styleId": 118204,
"companyContact": {
"name": "Jamie Rivera",
"email": "maria.hansen@example.com",
"status": "active"
},
"supplierContact": {
"name": "Alex Kim",
"email": "wei.chen@example.com",
"status": "active"
},
"supplierCountry": {
"id": 45,
"customId": "CN",
"name": "China"
}
},
{
"styleId": 118205,
"companyContact": {
"name": "Jamie Rivera",
"email": "maria.hansen@example.com",
"status": "active"
},
"supplierContact": null,
"supplierCountry": null
}
],
"pagination": {
"hasMore": true,
"cursor": "eyJTaWduYXR1cmUiOiJhYmMxMjMifQ=="
}
}
```
For the org-wide list, prefer the `cursor` over `pageNumber`: the styles table is large (1M+ rows
per platform), and cursor paging stays stable as new styles are created. The only sortable property
is `styleId`.
## Field reference
The fields that matter most when reading a style's contacts and supplier:
| Field | What it means at Delogue |
| ----------------- | ------------------------------------------------------------------------------------------------------------------ |
| `companyContact` | The company (designer-side) contact person for the style; null when the style has no company contact set. |
| `styleId` | Unique identifier of the style this contact row belongs to. |
| `supplierContact` | The supplier-side contact person for the style; null when the style has no supplier contact set. |
| `supplierCountry` | Country the style's supplier is registered in; null when the style has no supplier or the supplier has no country. |
## Roles & permissions
Reading a style's contacts requires **read** access on the **`styles`** permission; reading the
supplier sub-resource (`GET /api/styles/{styleId}/supplier`) requires **read** access on the
**`suppliers`** permission. Both are ordinary style-viewing actions available to the regular
designer and supplier roles — `CompanyAdmin`, `CompanyUser`, `SupplierAdmin`, and `SupplierUser` —
not an admin-only surface. Style ownership is enforced separately, so you only ever see contacts on
styles your organisation can access.
## When things go wrong
Errors use the standard envelope (`status: "error"`, a `code`, and `error.details[]`). A style that
belongs to another organisation returns **403**; a style that does not exist returns **404**; an
invalid filter, sort, or page argument on the org-wide list returns **400**. See
[Errors & responses](/concepts/errors) for the full list of codes and how to resolve them.
## What to call next
Read and manage the styles these contacts belong to, and set the supplier and contact people.
Explore the supplier's own sub-supplier network for supply-chain transparency.
Look up the supplier's production facilities that sit behind these contacts.
How to get and send your `X-Auth-Token` API key.