The WISECP API

12 views Markdown

What the API is, which surface answers which caller, and the first call you can make against an installation.

Overview

The API is a second way into the same installation. Everything it exposes is the work the panel already does: creating a client, opening an invoice, provisioning a service, reading a ticket. The difference is who asks. The panel is for a person at a screen; the API is for your code.

It speaks JSON over HTTPS with real HTTP methods and real status codes. A call carries an API key, never a session cookie, so nothing about it depends on someone being logged in.

It is not a mirror of the database. A resource is a business action with its rules attached. A call goes through the same guards the panel does: permissions, validation, hooks, activity records.

Prerequisites

The address of an installation you are allowed to integrate with.
An API key. Which kind depends on the surface you need, and the next article covers both.
A client that can send a request header. Anything can call this API; the samples use cURL, JavaScript and PHP.

Structure

There are three surfaces under /api/v1, and the segment after the version decides which one answers.

/api/v1/admin The operator's reach: every client, order, invoice, product and setting in the installation. Backs an internal tool, a migration or a reseller panel of your own.

/api/v1/client One customer managing their own account. Every call is bounded to the account the key belongs to, so a key can never read a neighbour.

/api/v1/<path> Paths a module publishes for itself. The installation ships none of its own here; what answers is whatever the installed modules registered.

The two credentialed surfaces are separate products, not one with a filter over it. A key issued for one is refused on the other, and the address is what tells them apart.

Example

The health check needs no key, so it is the honest first call. It proves the address is right and the API is reachable, before any credential is in play.

first call

curl 'https://panel.example.com/api/v1/admin/ping'
# {"data":{"pong":true,"version":"v1","time":"2026-08-06 10:12:41"}}

# with a key, this one reports who the key is and what it may do
curl -H 'Authorization: Bearer wak_...' \
     'https://panel.example.com/api/v1/admin/whoami'

Pitfalls

Nothing is pushed to you

There is no webhook delivery. An integration that needs to know when something happened has two options. It can ask again on a schedule, or run its own code inside the installation through a hook. Reacting to Events covers both.

v1 is frozen, and that is a promise to you

New endpoints, new response fields and new optional inputs keep arriving in v1. Removing a field, renaming one or changing a type does not. Neither does turning an optional input into a required one. That work waits for a v2, and an endpoint on the way out carries a Deprecation header with at least six months of overlap.

Was this helpful?

Thanks for your feedback!

Still Need Help?

Our support team is here around the clock for anything you can't find above.

Overview

Prerequisites

Structure

Example

Pitfalls

Related Articles