Hvordan automatiserer jeg provisioneringen som forhandler?

Du henter et forhandlertoken (rk_…) i Partners-kabinettet og kalder med det samme MCP-endpoint (eller REST-API'et). Tokenet er rollefiltreret: det åbner 30 reseller_*-værktøjer, der dækker hele kundens livscyklus — opret en plan, tilføj en kunde, bestil en VM til ham, læs status, suspendér, genaktivér, forny, opsig. At bestille en server til en kunde bliver ét autentificeret kald i stedet for en dashboardsession.

Hvad er forskellen på API og MCP her?

De samme evner, to døre. REST-API'et er det, du skripter fra din egen backend eller fakturering. MCP-endpointet åbner de samme reseller_*-værktøjer for en AI-agent eller MCP-kompatibel klient, så en model kan betjene dem direkte. Du kan bruge det ene eller begge — et faktureringswebhook, der provisionerer via REST, og en agent, der klarer resten via MCP.

Kan en AI-agent virkelig køre bestilling og suspendering?

Ja — det er, hvad MCP-fladen er til for. Fordi forhandlerværktøjerne er åbne for MCP, kan en agent autentificeret med dit rk_-token bestille en VM, når en kunde betaler, læse dens status, suspendere ved manglende betaling og genaktivere ved afregning, alt sammen uden et menneske, der klikker i et panel. Du fastsætter politikken; agenten udfører den.

Hvordan autentificeres og afgrænses min forhandleradgang?

Med et forhandlertoken (rk_…) sendt som Authorization: Bearer rk_… . Det er rollefiltreret til kun reseller_*-værktøjerne, så det opererer dine kunder og dine planer, ikke platformen som helhed. Hold tokenet hemmeligt som enhver adgangsoplysning; det er nøglen til hele din kundeflåde.

Skal jeg automatisere alt på én gang?

Nej. Begynd med at provisionere fra dashboardet, flyt så de mest hyppige handlinger til API'et, efterhånden som du vokser — som regel bestil-ved-betaling og suspendér-ved-manglende-betaling først. Pointen er, at den operationelle indsats holder op med at skalere med kundeantallet, så snart de to er automatiseret, og det er det, der gør en stor forhandlerbog profitabel.

Automatisér din VPS-forhandlervirksomhed via API og MCP

En forhandlervirksomhed, der køres i hånden, rammer hurtigt et loft: hver bestilling, hver suspendering, hver fornyelse er et menneske, der klikker i et panel, og din tid vokser med dit kundeantal. Vejen forbi det loft er at køre driften som kode — og EQVPS åbner forhandlersiden både via en REST-API og et MCP-endpoint, så du kan skripte den eller overdrage den til en AI-agent.

Ét token, 30 forhandlerværktøjer

Du henter et forhandlertoken (rk_…) i Partners-kabinettet og sender det som Authorization: Bearer rk_…. Tokenet er rollefiltreret: det åbner 30 reseller_*-værktøjer på det samme MCP-endpoint, der dækker hele kundens livscyklus:

opret en plan og fastsæt dens pris,
tilføj en kunde,
reseller_order_for_client — bestil en VM under dit brand,
læs dens status,
reseller_suspend_client / reseller_unsuspend_client — suspendér og genopret,
forny og opsig.

At bestille en server holder op med at være en dashboardsession og bliver ét autentificeret kald.

API eller MCP — de samme evner, to døre

Det er ikke konkurrerende muligheder; det er to indgange til de samme værktøjer:

REST-API — det, du skripter fra din egen backend eller fakturering. Et betalingswebhook affyres, din kode kalder bestillings-endpointet, VM'en provisioneres under dit brand.
MCP-endpoint — de samme reseller_*-værktøjer åbnet for en AI-agent eller MCP-kompatibel klient, så en model betjener dem direkte.

De fleste forhandlere bruger begge: et faktureringswebhook, der provisionerer via REST, og en agent, der klarer de mere drilske beslutninger via MCP.

Voldgraven: en agent, der kører driften

Her holder det op med at ligne ethvert andet forhandlerprogram. Fordi forhandlerværktøjerne ligger på MCP, kan en AI-agent autentificeret med dit rk_-token køre virksomheden direkte — bestille en VM, når en kunde betaler, læse status, suspendere ved manglende betaling, genaktivere ved afregning — uden menneske i løkken. Den samme platform, hvor en agent kan købe og køre sin egen server, lader en agent køre en flåde på vegne af dine kunder. Du fastsætter politikken; agenten udfører den. Det er den AI-drevne hostingvirksomhed som konkret mønster.

Et minimalt flow

// autentificér hvert kald med dit forhandlertoken
// Authorization: Bearer rk_...

reseller_order_for_client({ client_id, product: "small", os_id: 1 })  // provisionér under dit brand
// → service_id, ip, adgang — lever det til din kunde som dit eget
reseller_suspend_client({ service_id })       // ved manglende betaling
reseller_unsuspend_client({ service_id })      // ved afregning

Fire kald erstatter det, der før var en panelsession pr. kunde, pr. hændelse.

Ærlig rækkevidde

Tokenet er en adgangsoplysning. rk_… er nøglen til hele din kundeflåde — opbevar det som sådan, og rotér det ved eksponering.
Automatisering udfører din politik, ikke sin egen. En agent, der bestiller og suspenderer, er kun så god som de regler, du giver den; begræns forbruget med et forudbetalt saldo, så en fejl eller en dårlig prompt ikke løber løbsk.
Support og fakturering er stadig dine. Automatisering fjerner klikket, ikke kunderelationen.

Hvor du går hen nu

Den fulde reference — autentificering, reseller_*-værktøjer, os_id-håndtering og statusser — er i reseller-API-/MCP-dokumentationen. Ny på forretningssiden? Begynd med sådan starter du en VPS-forhandlervirksomhed. Engrossiden er white label-forhandlerprogrammet.