Bridging the two platforms
The only join between the two systems is the organization_id returned by the legacy customer list.
GET https://api.fsflt.net/customerarea/customers/list
Optional parameter: customer_code — as a distributor, returns the customers of that specific customer.
curl 'https://api.fsflt.net/customerarea/customers/list' \
-H 'Accept: application/json' \
-H 'X-API-KEY: YOUR_LEGACY_API_KEY'{
"code": 200,
"content": [
{
"main": false,
"code": 12345,
"name": "Mario",
"surname": "Rossi",
"email": "[email protected]",
"lang": "IT",
"country_code": "IT",
"company_name": "Rossi Srl",
"industry_code": 1,
"organization_id": "019f88ef-7fb5-725c-88e8-0d7028d1b392",
"migration_status": "MIGRATED",
"contacts": { "skype": "", "phone": "+390212345678" }
}
]
}Field | Meaning |
|---|---|
organization_id | The customer's identifier on the new platform. null if the customer is not yet provisioned/migrated |
migration_status | MIGRATED · NOT_MIGRATED· MIGRATION_STARTED |
Routing rule:
- organization_id present → the tenant exists on the Cloud Panel: configure policies and networks there, using that UUID as organizationId.
- organization_id null → the tenant is not (yet) available on the Cloud Panel: keep using customer_code and retry later — it may simply still be provisioning.
- Never attempt to use customer_codeas organizationId (or vice versa): different type, different platform.
Once the customer is created, it is automatically migrated to the new platform, and this happens in the background: it can take a few seconds. As a consequence, GET /customerarea/customers/list may return organization_id: null for a short while even though the tenant is already being provisioned. Poll the endpoint (e.g. 5 attempts with backoff over ~60 s) until the UUID appears, instead of treating a null value as a permanent "legacy-only" state.