Bouw je eigen bedieningsoppervlak

Het voorgestelde versie-één-contract scheidt catalogusbronnen van accountbronnen. Locaties en plannen ondersteunen configuratie. Diensten vertegenwoordigen geaccepteerde configuraties en fulfilmentstatus. Facturering bevat facturen en betalingsstatus. Tickets ondersteunen een traceerbaar supportgesprek. De website implementeert zijn eigen formulieren en werkruimte; de onderstaande voorbeelden zijn een ontwerpcontract, geen routes naar een openbare API.

Het voorbereide authenticatiemodel gebruikt een Bearer-token in de Authorization-header. Alleen-lezen catalogus- of servicescopes zouden geen service moeten kunnen aanmaken, herbouwen of annuleren. Schrijfscopes vereisen een afzonderlijke beslissing en intrekkingspad. Bewaar inloggegevens in een private serveromgeving en sluit nooit een geheim token in een pagina of browserbundel in.

GET /v1/services
Authorization: Bearer <private-token>
Accept: application/json

# Proposed scope: services:read

Gebruik een stabiele identificatie voor elke resource en een verzoek-ID voor ondersteuning. Muterende aanroepen moeten een idempotentiesleutel hebben, zodat een nieuwe poging kan worden verzoend in plaats van een nieuwe bestelling te creëren.

POST /v1/services
Idempotency-Key: <one-key-per-request>

{
  "plan_id": "umbra-1",
  "location": "iceland",
  "billing_cycle": "monthly",
  "image": "Ubuntu"
}

De voorgestelde limieten op accountniveau zijn 60 reads per minuut en 20 writes per minuut, met een bursttoeslag van het dubbele van die waarden. Een afgewezen verzoek retourneert HTTP 429 met Retry-After; automatisering moet wachten zoals geïnstrueerd en backoff toepassen. Fouten moeten een stabiele code, een voor mensen leesbare melding en een request_id bevatten, met gevoelige details verwijderd.

{
  "error": {
    "code": "unsupported_location",
    "message": "This plan is not listed in that region.",
    "request_id": "req_example"
  }
}

Het voorbereide webhookmodel dekt factuurbetaling, gereedheid van de dienst, opschorting en ticketupdates. Levering moet een event-ID en tijdstempel hebben, met een HMAC-SHA256-signatuur die wordt gecontroleerd over de oorspronkelijke request-body met een private signing secret. Weiger verouderde of ongeldige signaturen, dedupliceer event-ID's en bevestig pas nadat de gebeurtenis duurzaam is geaccepteerd. Consumers moeten levering buiten volgorde en herhaalde levering tolereren.

Het voorgestelde API-pad bevat het hoofdversienummer. Additieve wijzigingen moeten bestaande clients behouden; incompatibele wijzigingen vereisen een nieuwe versie en een uitfaseringsaankondiging van zes maanden voor de oude. Beschikbaarheid, SDK's en een productie-API-host mogen pas worden gepubliceerd na integratie- en beveiligingsbeoordeling.

De accountapplicatie heeft betaalverzoeken met vast adres en aflopende server-USD-offertes. Transactieobservatie is een vertrouwde server-only integratie; er is geen openbaar bevestigingseindpunt, aangesloten blockchainmonitor of provisioning-worker. Browserpolling leest de bestaande betaalstatus van de ingelogde klant en kan geen transactie attesteren. Het illustratieve openbare API en webhookcontract hierboven blijven toekomstig ontwerpwerk.

• Bescherm de tarief- en observatielogica op de server.
• Koppel hergebruikte ontvangstbestemmingen aan een geverifieerde transactie en een expliciete orderreferentie.
• Houd betaald en ingericht gescheiden; een geverifieerde transactie mag geen fictieve hardware creëren.