Venda a hospedagem Zinn® a partir do HostBill, Blesta ou do seu próprio sistema

Se você usa o WHMCS, use o módulo do WHMCS em vez disso — esta página é para todo o resto. Há duas opções, ambas gratuitas e ambas GPL-2.0-or-later.

HostBill

Um módulo de hospedagem com as mesmas seis ações que o do WHMCS.

Baixe-o e descompacte.
Envie o diretório zinn para includes/modules/Hosting/ para que os arquivos fiquem em

includes/modules/Hosting/zinn/class.zinn.php e includes/modules/Hosting/zinn/ZinnHostBillClient.php.

Configurações (Settings) → Módulos (Modules) → Hospedagem (Hosting), ative Zinn Digital® e adicione uma conexão:

Endereço da API: https://api.zinndigital.com
Chave da API: sua chave de API da Zinn® (um campo de senha, para que o HostBill a armazene criptografada)

No produto, defina a Linha de produto (por exemplo, mainstream), Stack (wordpress por

padrão) e, opcionalmente, Aplicativo e Versão do PHP.

Pressione Testar conexão.

⛔ Não renomeie o diretório zinn. O carregador do HostBill deriva a classe que ele procura a partir do nome do diretório, portanto, uma renomeação produz um módulo que o painel lista, mas nunca chama.

Qualquer outra coisa — o cliente PHP

Um arquivo, sem dependências, sem suposições de painel. Coloque ZinnProvisioning.php no seu próprio código e chame seis métodos.

require_once 'ZinnProvisioning.php';

$zinn = new ZinnProvisioning(getenv('ZINN_API_KEY'));

// When an order is paid — once per CUSTOMER, then once per SERVICE:
$orgId  = $zinn->account('customer-4211', 'Acme Ltd');
$siteId = $zinn->provision('service-9915', $orgId, 'acme.com', 'mainstream', 'wordpress');
// Store $orgId against your customer and $siteId against your service.

$zinn->suspend($siteId, 'INV-2026-114 unpaid');   // an invoice goes unpaid
$zinn->unsuspend($siteId);                        // they pay
$zinn->terminate($siteId);                        // they cancel — schedules a deletion

// When they click "log in to my hosting" — mint it on the CLICK, never on page render:
header('Location: ' . $zinn->signInLink($siteId));

Não está escrevendo em PHP? As mesmas chamadas estão na referência da API e você pode fazê-las a partir de qualquer coisa.

A chave da API

Sete permissões, e nenhuma a mais: org.create, org.read, sites.create, sites.view, sites.delete, reseller.view, reseller.provision.

⛔ Não reseller.manage. Uma chave que você cola em um painel de faturamento deve ser capaz de suspender um cliente por falta de pagamento e fazer o login dele; ela não deve ser capaz de reescrever suas próprias credenciais de gateway de pagamento.

As duas regras que custam dinheiro quando são quebradas

Vincule a conta ao seu CLIENTE, e o site ao seu SERVIÇO. O segundo pedido de um cliente

deve cair na conta que ele já tem. Vincular ambos ao serviço faz com que um cliente acabe com três contas não relacionadas e três painéis de controle separados.

Envie uma chave de idempotência em cada criação, derivada do seu próprio id para o item. Todo

sistema de faturamento tenta novamente — um retorno de chamada (callback) do gateway chega duas vezes, um administrador reexecuta um provisionamento falho, um cliente clica duas vezes. Sem isso, a segunda tentativa cria um segundo site e você é cobrado por ele. Ambos os módulos e o cliente PHP fazem isso por você; se você estiver chamando a API diretamente, envie Idempotency-Key.

Três campos fáceis de esquecer

Cada um deles quebra um verbo inteiro, e nenhum aparece como nada além de um erro de validação — exceto o primeiro, que aparece como absolutamente nada:

⛔⛔ Um cliente deve ser colocado em um plano ANTES que seu primeiro site seja provisionado, com

POST /v1/reseller/clients/{orgId}/plan, e o seu subscription_id passado para POST /v1/sites. Este é o caso que não apresenta nenhum erro para leitura. Uma nova conta de cliente não possui assinatura e POST /v1/sites não tem campo de plano, portanto, um site provisionado sem um carrega nenhum plano: sua declaração de atacado é construída a partir das assinaturas ativas de seus clientes, de modo que nenhuma linha é gerada e a Zinn® não lhe cobra nada enquanto a hospedagem estiver rodando; seu cliente não herda nenhuma franquia, portanto, nenhuma cota é aplicada ao site dele; e não há nada para uma atualização (upgrade) alterar. O pedido retorna 201, o site é provisionado e funciona perfeitamente. Nada em nenhuma das pontas relata qualquer problema.

A ordem importa: POST /v1/sites registra qualquer assinatura que exista no momento em que é executado, portanto, um plano definido posteriormente não é anexado retroativamente.

POST /v1/sites exige stack_type. Omiti-lo fará com que nenhum pedido possa ser bem-sucedido.
**DELETE /v1/sites/{siteId} exige um corpo `{"confirm_domain": "<the site's own

domain>"}** — uma confirmação digitada, porque este é o verbo destrutivo. Omiti-lo fará com que nenhuma cancelamento possa ser bem-sucedido, portanto, o serviço continua rodando e você continua sendo cobrado por ele. Leia o domínio de volta de GET /v1/reseller/services/{siteId}` em vez de usar seu próprio registro: ele é comparado com o domínio principal do próprio site e nunca com um alias.

Leia o erro inteiro, não apenas a frase

A mensagem de recusa de validação é propositalmente genérica — "The request was well-formed but failed validation." — porque a metade acionável está em details, que nomeia o campo e o motivo. Ambos os módulos e o cliente PHP anexam isso à mensagem que exibem ao seu administrador. Se você estiver chamando a API por conta própria, leia error.details; algumas entradas contêm um valor bruto em vez de uma frase, que é como max_sites: 0 chega até você quando seu plano de revendedor não tem espaço.

Antes do seu primeiro pedido

Os sites que seus clientes compram contam para a franquia de sites do seu plano de revendedor, então você precisa de um plano com espaço disponível. Um teste de conexão não consegue detectar isso — ele lê seu programa e não provisiona nada — portanto, ele relata uma conta saudável que ainda não pode vender. Um pedido feito sem franquia é recusado com uma mensagem dizendo exatamente isso.

Verifique seu download

Ambos os arquivos são servidos via TLS a partir de nosso próprio nome de host, nunca redirecionados para outro lugar, com suas somas de verificação SHA-256 impressas ao lado dos links de download na página de downloads.