Vendere l'hosting Zinn® dai propri sistemi

Lei rivende il nostro hosting. I clienti sono suoi: i suoi prezzi, le sue fatture, il suo fornitore di pagamento. Ecco come gestisce la nostra piattaforma da ciò che già utilizza — un pannello di fatturazione, il suo sito WordPress o uno script.

Cosa vedono effettivamente i suoi clienti

Prima della meccanica: i suoi clienti non devono mai vederci. Tre superfici e lei sceglie quale utilizzare.

⛔ Qualunque opzione scelga, lei è l'esercente ufficiale per i suoi clienti: i suoi prezzi, le sue fatture, la sua partita IVA, il suo fornitore di pagamento. Fatturiamo a lei, una volta al mese, all'ingrosso.

Una volta impostato un hostname del pannello, lo inserisca nel campo Indirizzo del pannello del plugin WordPress e in nient'altro — i collegamenti di accesso che questa API genera lo seguono automaticamente.

I quattro modi di accesso

Ci sono quattro modi di accesso e, a livello sottostante, fanno tutti la stessa cosa:

1. Ottenga una chiave API

Nella sua dashboard, vada su Chiavi API e ne crei una. Le assegni solo ciò di cui ha bisogno:

⛔ Non assegni a un'integrazione reseller.manage. Tale autorizzazione modifica il suo listino prezzi e le credenziali del suo gateway di pagamento. reseller.provision esiste proprio affinché una chiave che incolla in un pannello di fatturazione o in un sito web non ne abbia bisogno.

La chiave viene mostrata una sola volta. La conservi dove conserva le altre credenziali — mai in un file servito dal suo server web.

2. Effettui la prima chiamata

curl https://api.zinndigital.com/v1/reseller/services \
  -H "Authorization: Bearer zdk_live_…"

Restituisce ogni servizio di cui ha effettuato il provisioning, una riga per sito, con il cliente a cui appartiene, il suo stato e quanto addebita per esso. Su un account nuovo è un elenco vuoto — che è la risposta corretta, non un errore.

3. L'intera integrazione, in sei chiamate

WHEN                 CALL
an order is paid     POST   /v1/orgs                                   once per CUSTOMER
                     POST   /v1/sites                                  once per SERVICE
they have not paid   POST   /v1/reseller/services/{siteId}/suspend
they pay             POST   /v1/reseller/services/{siteId}/unsuspend
they cancel          DELETE /v1/sites/{siteId}
"log in to hosting"  POST   /v1/reseller/services/{siteId}/sso

Il provisioning consiste in due chiamate e le chiavi sono importanti:

# 1. the customer's account — keyed on YOUR customer id
curl -X POST https://api.zinndigital.com/v1/orgs \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: account-4211" \
  -d '{"type":"customer","name":"Acme Ltd"}'

# 2. their site — keyed on YOUR service id
curl -X POST https://api.zinndigital.com/v1/sites \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: service-9915" \
  -d '{"org_id":"<from step 1>","product_line":"mainstream","primary_domain":"acme.com"}'

Due regole che costano denaro se le sbaglia

1. Usi il suo CUSTOMER come chiave dell'account e il suo SERVICE come chiave del sito. Il secondo ordine di un cliente deve confluire nell'account che già possiede. Se usa il servizio come chiave per entrambi, un cliente finisce con tre account non correlati e tre pannelli distinti.
2. Invii un Idempotency-Key su ogni POST, costruito dal suo id per l'oggetto. Ogni sistema di fatturazione ritenta — un callback del gateway arriva due volte, un amministratore riesegue un provisioning non riuscito, un cliente fa doppio clic. Senza la chiave il secondo tentativo crea un secondo sito e le viene addebitato.

Tre risposte che non deve appiattire in due

• unsuspend può rispondere 409. Significa che il nostro team antabuso sta trattenendo il sito, non lei. Mostri il messaggio; non lo ritenti.
• **La terminazione pianifica un'eliminazione, non la esegue.** La data viene restituita come pending_deletion_at. Dire a un cliente che i suoi dati sono già scomparsi quando non lo sono è peggio che non dirgli nulla.
• disk_used_bytes può essere null e null non è zero. Significa che non siamo riusciti a misurare, non che non sia stato usato nulla. Lo salti — non scriva 0 nei suoi record, altrimenti mostrerà a un cliente una barra di utilizzo verde per un sito di cui non ha alcuna lettura.

4. Faccia accedere un cliente

POST /v1/reseller/services/{siteId}/sso restituisce un URL monouso che porta il suo cliente direttamente nel proprio account, già autenticato.

⛔ Lo generi quando fanno clic, mai quando esegue il rendering della pagina. Il collegamento è monouso e scade entro pochi minuti, quindi un collegamento scritto in una pagina viene bruciato alla prima visualizzazione e resta in ogni cache tra lei e il browser.

5. Installi invece un modulo

• WHMCS — copi il modulo in modules/servers/zinn/, aggiunga un server la cui Password è la sua chiave API e imposti la linea di prodotto sul prodotto. Prema Test Connection: effettua una chiamata reale e le dice cosa ha risposto la piattaforma.
• HostBill — copi in includes/modules/Hosting/zinn/ e lo colleghi allo stesso modo.
• WordPress — il Zinn® Reseller Toolkit: ricerca di domini, un collegamento di accesso all'hosting dei suoi clienti e provisioning WooCommerce quando un ordine viene pagato. Open source all'indirizzo <https://github.com/Zinn-Digital/zinn-reseller-toolkit>, oppure lo scarichi da Plugin nella sua dashboard.

6. Vada in produzione

Controlli questi punti prima di accettare un ordine reale:

• Il test di connessione sul modulo va a buon fine, oppure il suo primo curl restituisce un elenco.
• Il suo listino prezzi è impostato (Rivendita → I suoi prezzi).
• Il suo gateway di pagamento è collegato (Rivendita → Gateway di pagamento) — i suoi clienti pagano lei, tramite il suo account.
• I dati della sua azienda sono inseriti (Rivendita → La sua azienda) in modo che le fatture dei suoi clienti riportino la sua ragione sociale e la sua partita IVA, non le nostre.
• Ha effettuato un ordine reale dall'inizio alla fine e ha visto comparire il sito.

Dove si trova tutto il resto

Il riferimento API completo — ogni endpoint, generato dalla nostra specifica, con l'autorizzazione di cui ciascuno ha bisogno — è all'indirizzo <https://zinndigital.com/developers/api>.