API Delete: eliminare record con DELETE

DELETE · Controlli di sicurezza

API di eliminazione

Elimina i record in modo sicuro. Con controlli di sicurezza integrati contro la cancellazione accidentale dei dati dipendenti.

DELETE /xpanel/xoport/Delete/JSON/{entity}/{id}
Attenzione: a partire dalla versione 2.70.0, il metodo è obbligatorio: gli endpoint all'indirizzo Delete/JSON/ accettano esclusivamente il metodo HTTP DELETE. Qualsiasi altro metodo riceve in risposta dall’interfaccia un codice di stato 405 METHOD_NOT_ALLOWED e il campo dell’intestazione Allow: DELETE – prima che avvenga qualsiasi operazione. Si prega di verificare la propria connessione: finora il metodo non veniva verificato in questa sede, pertanto anche una chiamata tramite GET comportava la cancellazione. Se il vostro programma utilizza GET o POST, vi preghiamo di impostarlo su DELETE.

Endpoint disponibili

EndpointDescrizioneAmbitoControlli di sicurezza
DELETE /Delete/JSON/product/{id}Elimina prodottoproducts:delete-
DELETE /Delete/JSON/categories/{id}Elimina categoriacategories:deleteSottocategorie, prodotti
DELETE /Delete/JSON/customer/{id}Elimina clientecustomers:deleteOrdini
DELETE /Delete/JSON/manufacturer/{id}Elimina produttoremanufacturers:deleteProdotti
DELETE /Delete/JSON/supplier/{id}Elimina fornitoresuppliers:deleteProdotti
DELETE /Delete/JSON/customer_group/{id}Elimina gruppo clienticustomer_groups:deleteGruppo 0 bloccato (403 PROTECTED_GROUP), clienti associati (409 HAS_CUSTOMERS)
DELETE /Delete/JSON/newsdesk/{id}Elimina articolo delle notizienews:delete-
DELETE /Delete/JSON/newsdeskcat/{id}Elimina categoria di notizienewscategories:deleteSottocategorie, articoli
DELETE /Delete/JSON/faq/{id}Elimina FAQfaq:delete-
DELETE /Delete/JSON/faqcat/{id}Elimina categoria FAQfaqcategories:deleteSottocategorie, voci delle FAQ
DELETE /Delete/JSON/cms/{id}Elimina pagina CMScms:deletePagine di sistema con ID da 1 a 999 (409 PROTECTED_SYSTEM_PAGE), pagine bloccate (409 CONTENT_LOCKED)
DELETE /Delete/JSON/seohistory/{id}Elimina cronologia SEOseohistory:deleteEliminazione in blocco, filtri, scaduti
DELETE /Delete/JSON/newsletter_subscriber/{id}Elimina un iscritto alla newsletter newsletter:deleteCascata GDPR, sincronizzazione provider, eliminazione in blocco
DELETE /Delete/JSON/newsletter/{id}Elimina campagna newsletter newsletters:deleteVerifica blocchi, verifica invii (409)
DELETE /Delete/JSON/contract/{id}Elimina contrattocontracts:deleteLotteria tramite JSON-Rumpf {"data": [{"contracts_id": …}]}; ⚠️ nessun blocco in caso di fatture collegate o in sospeso (vedi Controlli di sicurezza)
DELETE /Delete/JSON/ticket/{id}Eliminazione ticket NOVITÀtickets:deleteCascata: Cronologia, Amministratori, Seguaci, Appuntamenti, File
DELETE /Delete/JSON/media/{id}Elimina immagine NOVITÀ v2.16.0media:deleteElaborazione in batch tramite ?entity_id= (tutte le immagini di un prodotto) o JSON-Stub {"ids": […]}; se si trattava dell’immagine principale, il campo immagine del prodotto viene svuotato
DELETE /Delete/JSON/slider/{id}Elimina slider NOVITÀ v2.22.0slider:delete-
DELETE /Delete/JSON/project/{id}Elimina progetto xoCRM NOVITÀ v2.35.0projects:deleteCascata: attività, descrizioni, responsabili, clienti, categorie, cronologia degli stati; gli ordini/i ticket vengono solo disaccoppiati
DELETE /Delete/JSON/project_task/{id}Elimina attività di progetto NOVITÀ v2.35.0project_tasks:deleteCascata: descrizioni, responsabili, clienti, categorie, cronologia degli stati (il progetto rimane)
DELETE /Delete/JSON/appointment/{id}Elimina appuntamento (cancellazione temporanea) NOVITÀ v2.44.0appointments:deleteImposta deleted_at (CalDAV-Tombstone); le descrizioni e i collegamenti vengono mantenuti
DELETE /Delete/JSON/order_status_history/{id}Elimina voce della cronologia di un ordine NOVITÀ v2.95.0orders:writeLo stato dell’ordine viene aggiornato; la voce più vecchia viene protetta (409)
DELETE /Delete/JSON/ticket_status_history/{id}Elimina voce di cronologia di un ticket NOVITÀ v2.95.0tickets:deleteLo stato del ticket viene aggiornato
DELETE /Delete/JSON/ticket_attachment/{tshid}?filename=…Rimuovere l'allegato di un ticket NOVITÀ v2.97.0tickets:deleteFile solo se nessun'altra voce lo contiene
DELETE /Delete/JSON/ticket_department/{id}Elimina reparto del ticket NOVITÀ v2.103.0tickets:deleteOccupato: 409 – ?reassign_to={id} oppure ?force=1

L'ID è presente nel percorso (/{entity}/{id}). Senza di esso, ad esempio con ?products_id=42, lo shop risponde con un errore HTTP 400 MISSING_ID e non elimina nulla; i parametri di query sconosciuti vengono ignorati. Senza ID nel percorso, vengono eliminati solo i contenuti multimediali, la cronologia SEO, gli iscritti alla newsletter e i contratti, tramite filtri o un payload JSON. In assenza di entrambi, viene restituito un errore HTTP 400 (NO_TARGETS, MISSING_FILTER o MISSING_DATA).

Inviare l’ID come numero intero senza caratteri residui, cifre decimali o segno. La verifica rigorosa del segmento di percorso, presente nell’esportazione dalla v2.122.12 (vedi API di esportazione), non si applica alla funzione di eliminazione.


Controlli di sicurezza

Alcune risorse non possono essere eliminate se esistono dati dipendenti (HTTP 409, non viene eliminato nulla):

Categorie

  • HAS_SUBCATEGORIES: ha sottocategorie
  • HAS_PRODUCTS: Contiene prodotti

Categorie di notizie

  • HAS_SUBCATEGORIES: Ha sottocategorie
  • HAS_NEWS: Contiene articoli di attualità

Clienti

  • HAS_ORDERS: Presenta ordini
Contratti senza blocco: DELETE /Delete/JSON/contract/{id} e la funzione di eliminazione in batch tramite JSON-Rumpf cancellano un contratto anche se vi sono fatture ad esso collegate o ancora in sospeso, proprio come avviene con la cancellazione nel backend. Gli ordini rimangono, viene semplicemente eliminato il collegamento al contratto. Successivamente, un addebito tramite mandato SEPA non potrà più raggiungere queste fatture. Verificate le fatture prima della cancellazione: quelle collegate sono elencate in orders[] da GET /Export/JSON/contract/{id}, ciascuna con il proprio stato dell’ordine orders_status. Per verificare se uno stato è considerato pagato, consultate is_paid in GET /Export/JSON/order_statuses (Ordini, sezione «Dati anagrafici dello stato dell’ordine»); l’ordine stesso è disponibile su GET /Export/JSON/order/{orders_id}.

Parametri di interrogazione v2.122.10

Ogni parametro di interrogazione di un endpoint di cancellazione è soggetto a una regola. Prima che il negozio proceda alla cancellazione, viene effettuato un controllo: un valore non valido o un valore presente nell’elenco (?param[]=…) genera un errore HTTP 400 INVALID_FILTER_VALUE, mentre details[] rimanda rispettivamente a param e message a seconda dell’errore, e non viene cancellato nulla.

EndpointParametri e regola
ogni endpoint di cancellazionelanguage un singolo valore (solo la regola dell’elenco; nessun endpoint di cancellazione legge la lingua)
DELETE /media(s)entity_id numero intero
DELETE /seohistory(s)type c, , , , o · numero intero · interruttori / · Non applicato s m p n o base_id expired 01 seo_string dalla v2.122.11: HTTP 400, nulla cancellato
DELETE /ticket_attachment/{id}filename Nome file senza percorso; se manca, viene restituito un errore HTTP 400 MISSING_FILENAME, con percorso viene restituito un errore HTTP 400 INVALID_FILENAME
DELETE /ticket_department/{id}reassign_to numero intero a partire da 0 (il reparto a cui vengono trasferiti i ticket) · force 1 /true/yes oppure 0/false/no, non fa differenza se maiuscolo o minuscolo
  • Un valore vuoto o solo uno spazio significa «non impostato». A partire dalla versione v2.122.12, gli spazi ai margini non vengono conteggiati: l’eliminazione avviene in base al valore verificato. Nei negozi precedenti alla versione 4.9.173, inviare valori senza spazi ai margini e omettere i parametri vuoti. I valori validi senza spazi ai margini funzionano come prima.
  • A differenza dell’esportazione, l’endpoint Delete ignora i nomi dei parametri sconosciuti.
  • A partire dalla versione v2.122.11, il filtro degli indirizzi seo_string funziona solo con il metodo GET. È possibile trovare le voci relative a un vecchio indirizzo tramite GET /Export/JSON/seohistorys?seo_string=… ed eliminarle tramite il loro sh_id: DELETE /Delete/JSON/seohistory/{sh_id} oppure con il tronco {"type": "seohistory", "data": [{"sh_id": …}]}. Fino alla v2.122.10 il nome veniva ignorato e l’eliminazione avveniva esclusivamente in base a type e base_id; con ?type=p venivano quindi eliminate tutte le voci relative ai prodotti.
DELETE /Delete/JSON/seohistorys?type=p&base_id=abc

HTTP 400
{
  "success": false,
  "api_version": "2.122.12",
  "error": {
    "code": "INVALID_FILTER_VALUE",
    "message": "One or more query parameter values could not be used. Nothing was deleted — see \"details\"."
  },
  "details": [
    { "param": "base_id", "message": "Value \"abc\" is not an integer." }
  ]
}
Modificato nella v2.122.10: fino alla v2.122.9, ogni endpoint di cancellazione leggeva autonomamente i propri parametri e un valore non valido influiva silenziosamente su ciò che veniva cancellato: DELETE /seohistorys?type=p&base_id[]=42 (così come base_id=abc) cancellava tutte le voci di tipo p, ?type=p&expired=yes tutte tranne quelle scadute; DELETE /ticket_department/{id}?reassign_to[]=5 ha spostato i ticket nel reparto 1, ?reassign_to=5abc nel reparto 5. Ora si verifica un errore HTTP 400 e non viene eliminato nulla.
Modificato nella v2.122.12: fino alla v2.122.11, il negozio verificava i valori senza spazi ai margini, ma l’endpoint di cancellazione leggeva poi il valore non troncato. Ora cancella in base al valore verificato. ⚠️ Non elimina mai più di quanto indicato dai valori verificati, ma elimina comunque più dati rispetto a prima: le richieste che fino alla v2.122.11 venivano respinte per mancanza di una condizione valida, ora vengono elaborate (righe contrassegnate con ⚠️).
Richiestafino alla v2.122.11a partire dalla v2.122.12
DELETE /seohistorys?type=p&base_id=42%00cancellava ogni voce del tipo psolo le voci relative all’articolo 42
DELETE /seohistorys?type=%20p&base_id=42ha eliminato le voci di ogni tipo relative all'ID 42solo quelle di tipo p con ID 42
DELETE /seohistorys?type=p&expired=1%00la condizione è stata eliminata: ha eliminato ogni voce del tipo psolo quelle scadute del tipo p
⚠️ DELETE /seohistorys?type=%20p senza ulteriori filtriHTTP 400 MISSING_FILTER, nulla cancellatoelimina tutte le voci di tipo p
⚠️ DELETE /seohistorys?base_id=42%00 o ?expired=1%00 da soliHTTP 400 MISSING_FILTER, nulla cancellatoelimina tutte le voci con ID 42 o tutte quelle scadute
⚠️ DELETE /medias?entity_id=7%00HTTP 400 NO_TARGETS ovvero solo gli ID presenti nel corpo del messaggioinoltre tutte le immagini dell’articolo 7: entity_id seleziona le destinazioni, non le limita
⚠️ DELETE /ticket_department/{id}?reassign_to=%005HTTP 409 DEPARTMENT_IN_USE, nessun trasferimentoBiglietti spostati nella sezione 5, sezione cancellata
DELETE /ticket_department/{id}?force=%20truecome se non ci fosse forceforce vale

Prima dell'aggiornamento, verificare se la propria connessione invia valori contenenti spazi, interruzioni di riga o %00 ai margini, ad esempio da un file importato: tali valori vengono ora considerati così come appaiono senza questi caratteri.

Formati di risposta

Cancellazione riuscita

{
  "success": true,
  "api_version": "2.122.12",
  "type": "newsdesk",
  "deleted_id": 23,
  "details": {
    "newsdesk_id": 23,
    "newsdesk_article_name": "Gelöschter Artikel"
  },
  "timestamp": "2026-10-18 14:00:00"
}

Cancellazione bloccata

{
  "success": false,
  "api_version": "2.122.12",
  "error": {
    "code": "HAS_SUBCATEGORIES",
    "message": "Cannot delete newsdesk category \"Shopnews\" (ID: 1): Has 3 sub-categories. Delete them first."
  }
}

Attenzione durante la cancellazione!

Le operazioni di cancellazione sono irreversibili. Creare prima un’esportazione come copia di backup.

Crea un'esportazione

Importazione dei dati con l'API xoPort

Gli endpoint di importazione consentono di inserire in modo efficiente i dati provenienti da sistemi esterni. Grazie alla logica intelligente di "upsert", non è necessario preoccuparsi di distinguere tra record nuovi ed esistenti.

Best practice

  • Utilizzate le importazioni in batch (max. 50 record) per ottenere prestazioni migliori
  • Controllate l’array «errors» nella risposta per individuare i record non importati correttamente
  • Implementate una logica di riprova per gli errori transitori
  • Convalidare i dati sul lato client prima dell’importazione