Deutsche Version

Back to overview

API Key Wildcard: Usage

Endpoint comparison

The standard endpoint stays unchanged and keeps working with IP-bound keys.

Create a ticket with curl

curl -X POST \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name":"Test User","email":"test@example.com","subject":"Test Ticket via Wildcard","message":"Message via the wildcard endpoint"}' \
  http://localhost/osTicket/api/wildcard/tickets.json

Supported routes

The wildcard endpoint has exactly one route: POST /tickets.json, POST /tickets.xml and POST /tickets.email, each below /api/wildcard. The ticket is created by osTicket's ticket controller, the plugin only replaces the API key check.

Other methods and other paths (for example ticket queries) are not passed through the wildcard check by the wildcard endpoint. Use the standard API with an IP-bound key for those.

Endpoints of other plugins

The wildcard endpoint sends the api signal with its dispatcher so that other plugins can attach routes. Such routes check the API key with their own logic and do not know the wildcard rule. A 0.0.0.0 key is not automatically valid for any IP there.

Behavior on errors

The responses with status 401 and their causes are listed under Troubleshooting.

Security notes

A wildcard key allows anyone who knows the key to create tickets from any IP. Use it only where that is acceptable.

Wildcard keys (0.0.0.0) are meant for development environments. In production, bind every key to a fixed IP.

• Not suitable: publicly reachable production servers, systems with sensitive data, regulated environments.
• Suitable: local development, internal networks behind a firewall, non-public test and staging environments.
• Separate keys: Use an IP-bound key on the standard endpoint for production and a separate wildcard key per person or tool for development.
• Key lost: Deactivate the key in the Admin Panel, create a new one and check the system log for Wildcard API Key Used entries.