Maxicom¶

Maxicom is a refurbished electronics supplier operating through the Alumio integration platform. Two separate connector configurations exist for Maxicom, each representing a different sales channel within the same Odoo/Alumio environment.

Website

Maxicom
Drop-ship

Direct shipment from Refurbisher to end customer
Integration

Via Alumio middleware platform
Currency

EUR

Status¶

Artifact	Acceptatie	Production
Refurbisher (Ch. 3)	`ID: 8` · → IRP	`ID: 8` · → IRP
Refurbisher (Ch. 10)	`ID: 26` · → IRP	`ID: 25` · → IRP
Supplier	`ID: 6` · → IRP	`ID: 6` · → IRP
Offer connector	Web POST · JSON · Header token (n8n) · →	Web POST · JSON · Bearer token (Alumio, deprecated) · n8n endpoint ready, IRP switch pending · →
Order connector (direct to Maxicom)	Not integrated	Not integrated
Shipment webhook (inbound from Maxicom)	Not configured	Not configured
Odoo/CITg order push	Active · →	Active · →

IRP¶

Maxicom (Sales Channel 3)¶

Field	Value
Refurbisher ID	`8`
Supplier ID	`6`
Odoo Vendor ID	`11682`
Currency	`EUR`
Shipping Costs	`€9.00`
Default Margin	`32%`
Stock Threshold	`0`
Approved Refurbished	No
Drop-ship	Yes

Maxicom 2 (Sales Channel 10)¶

Refurbisher ID differs per environment

For some reason there is a ID mismatch between acceptance and production.

It's ID is 26 on acceptance and 25 on production.

Field	Value
Refurbisher ID	`26` (acceptance) / `25` (production)
Supplier ID	`6`
Odoo Vendor ID	`11682`
Currency	`EUR`
Shipping Costs	`€9.00`
Default Margin	`32%`
Stock Threshold	`0`
Approved Refurbished	No
Drop-ship	Yes

Monitoring Thresholds¶

Metric	Threshold
Latest order (hours)	`51`
Offers stock (hours)	`22`
Open order (days)	`86`
Offers endpoint HTTP status	`586`

No automated order integration

Maxicom does not have an automated order integration. Orders must be processed manually. Only offer feeds are retrieved automatically via Alumio.

Alumio deprecated in favor of n8n

CITg is deprecating their Alumio middleware in favor of n8n. CITg's n8n endpoints are already functional for all three sales channels (Maxicom, Maxicom 2, iUsed) for both accept and production, the remaining work is purely switching the IRP-side connector config over, channel by channel. This is not blocked on CITg.

Acceptatie is fully on the new n8n endpoint/header-auth below, for both Maxicom (Sales Channel 3) and Maxicom 2 (Sales Channel 10). Production is still fully on the old (deprecated) Alumio endpoint for both channels, the n8n migration has not gone out to production yet, only acceptance.

Production sales order (IF003.05a) and delivery update (IF005.07d) push are also still on the old (deprecated) Alumio endpoints — CITg asked for these to be migrated to production next.

Tracked in ClickUp task IUS-3867.

Refurbisher Connector Config¶

config_key naming differs per environment — confirmed via DB on both

Verified by joining refurbishers (id, refurbisher_config_id) to refurbisher_configs (id, config_key):

Environment	Refurbisher	ID	`refurbisher_config_id`	Live `config_key`
Acceptatie	Maxicom 1 (Sales Channel 3)	`8`	`4`	`maxicom-alumio-uat`
Acceptatie	Maxicom 2 (Sales Channel 10)	`26`	`18`	`maxicom-alumio-uat-2`
Production	Maxicom 1 (Sales Channel 3)	`8`	`4`	`maxicom-alumio`
Production	Maxicom 2 (Sales Channel 10)	`25`	`18`	`maxicom-alumio-2`

Both environments now correctly resolve to two distinct config_keys each.

Acceptatie (n8n) — current Production — current (Alumio, deprecated) Production — target n8n (not yet applied)

Both maxicom-alumio-uat (refurbisher 8) and maxicom-alumio-uat-2 (refurbisher 26) are live on n8n. Both order blocks are pre-existing, disabled (enabled: false), and out of scope for the n8n migration.

config.json

"maxicom-alumio-uat": {
  "name": "Maxicom",
  "offers": {
    "enabled": true,
    "connection": "web_post",
    "endpoint": "https://connect.accept.circularit.group/webhook/odoo-citg/saleschannel/product/receive",
    "auth": { "type": "header_token", "http_header": "CITG-webhook-auth", "token": "<encrypted_token>" },
    "body": "{ \"sales_channel_id\": 3 }",
    "type": "json",
    "paginate": false,
    "offer_location": "offers",
    "price_locale": "en_US",
    "mapping": {
      "name": "description",
      "sku": "sku",
      "stock_available": "quantity",
      "ean": "ean",
      "price_purchase_amount": "costPrice",
      "price_consumer_amount": "costPrice",
      "currency_iso": "currencyIso",
      "tax_percentage": "taxPercentage"
    }
  },
  "order": {}
},
"maxicom-alumio-uat-2": {
  "name": "Maxicom via Alumio 2",
  "offers": {
    "enabled": true,
    "connection": "web_post",
    "endpoint": "https://connect.accept.circularit.group/webhook/odoo-citg/saleschannel/product/receive",
    "auth": { "type": "header_token", "http_header": "CITG-webhook-auth", "token": "<encrypted_token, distinct from maxicom-alumio-uat's>" },
    "body": "{ \"sales_channel_id\": 10 }",
    "type": "json",
    "paginate": false,
    "offer_location": "offers",
    "price_locale": "en_US",
    "mapping": {
      "name": "description",
      "sku": "sku",
      "stock_available": "quantity",
      "ean": "ean",
      "price_purchase_amount": "costPrice",
      "price_consumer_amount": "costPrice",
      "currency_iso": "currencyIso",
      "tax_percentage": "taxPercentage",
      "is_margin_forced": "marginProduct"
    }
  },
  "order": {}
}

What changed on maxicom-alumio-uat-2

Only endpoint and auth changed (new domain, header_token/http_header: "CITG-webhook-auth", matching the maxicom-alumio-uat pattern) — body, mapping (including is_margin_forced), and everything else stayed as they were. This connector has its own token from 1Password, distinct from maxicom-alumio-uat's.

config.json

"maxicom-alumio": {
  "name": "Maxicom via Alumio",
  "refurbisher_id": 8,
  "offers": {
    "connection": "web_post",
    "endpoint": "https://flooris.alumio.com/api/v1/http-proxy/odoo-max-receive-sales-channel-products",
    "auth": { "type": "bearer", "token": "XXXXXXXXXXXXXXX" },
    "body": "{ \"sales_channel_id\": 3 }",
    "type": "json",
    "paginate": false,
    "offer_location": "offers",
    "price_locale": "en_US",
    "mapping": {
      "name": "description",
      "sku": "sku",
      "stock_available": "quantity",
      "ean": "ean",
      "price_purchase_amount": "costPrice",
      "price_consumer_amount": "costPrice",
      "currency_iso": "currencyIso",
      "tax_percentage": "taxPercentage"
    }
  },
  "order": {}
},
"maxicom-alumio-2": {
  "name": "Maxicom via Alumio",
  "refurbisher_id": 8,
  "offers": {
    "connection": "web_post",
    "endpoint": "https://flooris.alumio.com/api/v1/http-proxy/odoo-max-receive-sales-channel-products",
    "auth": { "type": "bearer", "token": "XXXXXXXXXXXXXXX" },
    "body": "{ \"sales_channel_id\": 10 }",
    "type": "json",
    "paginate": false,
    "offer_location": "offers",
    "price_locale": "en_US",
    "mapping": {
      "name": "description",
      "sku": "sku",
      "stock_available": "quantity",
      "ean": "ean",
      "price_purchase_amount": "costPrice",
      "price_consumer_amount": "costPrice",
      "currency_iso": "currencyIso",
      "tax_percentage": "taxPercentage"
    }
  },
  "order": {}
}

refurbisher_id: 8 on both entries

This embedded field is cosmetic only (used in one exception-message string, app/Refurbishers/Traits/RefurbisherAuth.php:261 — never used for resolution), so the duplicate value is harmless. Real resolution goes through config_key, not this field.

CITg's production n8n domain is connect.circularit.group (mirrors the accept domain connect.accept.circularit.group). CITg's endpoint is reportedly already functional here too; the n8n migration has not gone out to production yet for either channel — not yet switched on the IRP side.

Confirmed: production's refurbisher → config link is correct

Verified via refurbishers ⋈ refurbisher_configs: refurbisher 8 ("Maxicom") → refurbisher_config_id 4 → config_key maxicom-alumio; refurbisher 25 ("Maxicom 2") → refurbisher_config_id 18 → config_key maxicom-alumio-2. Two distinct config_keys, correctly wired — production does not have acceptatie's duplicate-config bug. Safe to edit maxicom-alumio and maxicom-alumio-2 directly once this is picked up.

config.json (target, not yet applied)

"maxicom-alumio": {
  "name": "Maxicom via Alumio",
  "offers": {
    "enabled": true,
    "connection": "web_post",
    "endpoint": "https://connect.circularit.group/webhook/odoo-citg/saleschannel/product/receive",
    "auth": { "type": "header_token", "http_header": "CITG-webhook-auth", "token": "<encrypted_token>" },
    "body": "{ \"sales_channel_id\": 3 }",
    "type": "json",
    "paginate": false,
    "offer_location": "offers",
    "price_locale": "en_US",
    "mapping": {
      "name": "description",
      "sku": "sku",
      "stock_available": "quantity",
      "ean": "ean",
      "price_purchase_amount": "costPrice",
      "price_consumer_amount": "costPrice",
      "currency_iso": "currencyIso",
      "tax_percentage": "taxPercentage"
    }
  },
  "order": {}
},
"maxicom-alumio-2": {
  "name": "Maxicom via Alumio",
  "offers": {
    "enabled": true,
    "connection": "web_post",
    "endpoint": "https://connect.circularit.group/webhook/odoo-citg/saleschannel/product/receive",
    "auth": { "type": "header_token", "http_header": "CITG-webhook-auth", "token": "<encrypted_token, distinct from maxicom-alumio's>" },
    "body": "{ \"sales_channel_id\": 10 }",
    "type": "json",
    "paginate": false,
    "offer_location": "offers",
    "price_locale": "en_US",
    "mapping": {
      "name": "description",
      "sku": "sku",
      "stock_available": "quantity",
      "ean": "ean",
      "price_purchase_amount": "costPrice",
      "price_consumer_amount": "costPrice",
      "currency_iso": "currencyIso",
      "tax_percentage": "taxPercentage"
    }
  },
  "order": {}
}

Order Push to Odoo¶

Unlike the disabled per-refurbisher order connector above, Maxicom does participate in the portal-wide push of sales orders and delivery/shipment updates into Odoo via CITg's middleware — the same AlumioConnector integration migrated to n8n under IUS-3867. Unlike the offer connector above, this is not per-refurbisher config.json configuration — it's driven by portal-wide ALUMIO_CITG_MAXICOM_* env vars (config/services.php) and applies uniformly to all refurbishers/shops, aside from the exclusion below.

Interface	Trigger	Acceptatie (n8n)	Production (Alumio, deprecated)
IF003.05a — sales order push	Every order (`OrderRefurbisherOrdersCreatedEvent`), no exclusions	`POST .../webhook/odoo-citg/sales-order/create`	`POST .../api/v1/http-proxy/odoo-citg-send-saleorder`
IF005.07d — delivery/shipment update push	Every `RefurbisherOrderDelivery` created, except the Maxicom exclusion below	`POST .../webhook/odoo-citg/purchase-order/delivery`	`POST .../api/v1/http-proxy/odoo-citg-purchaseorder-delivery-update`

Auth on acceptatie is the same CITG-webhook-auth header-token mechanism as the offer connector, with two separate tokens (one per interface); production still uses a Bearer token.

Credentials

These tokens are portal-wide (not per-refurbisher) — one token per interface, shared across all shops/refurbishers:

Maxicom-specific exclusion for IF005.07d

PushRefurbisherOrderDeliveryListener::refurbisherIsExcluded() (app/Listeners/PushRefurbisherOrderDeliveryListener.php:127-156) skips the delivery-update push only when the order's own Shopware instance supplier and the fulfilling refurbisher are both Maxicom (Refurbisher::SUPPLIER_ID_MAXICOM = 6) — i.e. a pure Maxicom-internal sale that CITg/Odoo doesn't need to know about. For drop-ship orders placed on other shops (this refurbisher's actual use case — see the "Drop-ship: Yes" flag above), the push is not excluded and fires normally. IF003.05a has no equivalent exclusion; it always fires.

API Integration¶

Maxicom offers are retrieved via an HTTP POST request. Two separate sales channels are configured. CITg is deprecating Alumio in favor of n8n (IUS-3867) — acceptatie has switched over for both channels; production is still fully on Alumio for both, pending an IRP-side configuration change (the n8n endpoint itself is already functional, see warning above).

Credentials

Legacy Alumio Bearer token stored in 1Password under iUsed - IRP - Refurbisher: Maxicom.

New n8n header token (accept + production, both sales channels): IF001.10.a – Receive sales channel products from Odoo CITG [n8n]

Authentication Endpoints Offer Feed

Acceptatie (n8n) — custom header, no Bearer prefix, both channels:

CITG-webhook-auth: <TOKEN>
Content-Type: application/json

Production (Alumio, deprecated) — Bearer token, both channels:

Authorization: Bearer <TOKEN>
Content-Type: application/json

CITg's n8n endpoint is functional for both channels in both environments already (IUS-3867) — the production rows below reflect IRP's own connector config not having been switched over yet, not a CITg-side gap.

Status	Environment	Method	Endpoint	Sales Channel	Refurbisher ID
Live	Acceptatie	`POST`	`https://connect.accept.circularit.group/webhook/odoo-citg/saleschannel/product/receive`	`3`	`8`
Live	Acceptatie	`POST`	`https://connect.accept.circularit.group/webhook/odoo-citg/saleschannel/product/receive`	`10`	`26`
Deprecated (current)	Production	`POST`	`https://flooris.alumio.com/api/v1/http-proxy/odoo-max-receive-sales-channel-products`	`3`	`8`
Deprecated (current)	Production	`POST`	`https://flooris.alumio.com/api/v1/http-proxy/odoo-max-receive-sales-channel-products`	`10`	`25`
Target (not yet applied)	Production	`POST`	`https://connect.circularit.group/webhook/odoo-citg/saleschannel/product/receive`	`3`	`8`
Target (not yet applied)	Production	`POST`	`https://connect.circularit.group/webhook/odoo-citg/saleschannel/product/receive`	`10`	`25`

The sales channel is specified in the request body:

{ "sales_channel_id": 3 }

The offer feed is returned as a JSON object with an offers array. Fetched via HTTP POST to the endpoint in Endpoints above (format is unchanged now that Alumio is deprecated in favor of n8n).

Field	JSON Path
Name	`description`
SKU	`sku`
Stock	`quantity`
EAN	`ean`
Purchase Price	`costPrice`
Consumer Price	`costPrice`
Currency	`currencyIso`
Tax Percentage	`taxPercentage`

Format details

Type: json
Paginated: No
Price locale: en_US
Offer location: offers

A failed request looks the same as an empty feed

For type: json connectors, getOffersFromRequest() always extracts the offer_location key and ignores HTTP status codes (app/Refurbishers/Traits/RefurbisherOffersTrait.php). A wrong endpoint/auth (e.g. a 404 or 401 with a JSON error body) just resolves to null — no exception, and the "Download offers" button in the IRP UI will still produce a downloadable file, just containing null instead of real offers. Always open the result and confirm it has actual product data; if not, check storage/logs/refurbisher-offers.log for the real HTTP error.