Skip to content

Knowledgebase

Configure HostBill API access for an authorised integration

hostbill, development

Create a separate HostBill API identity for each authorised integration. Limit its functions and network access before giving the credentials to the application. This makes activity traceable and allows one integration to be retired without disrupting others.

01 Configure the API identity

  1. Document the integration's purpose, owner, required API methods and outbound IP addresses. Determine whether it needs only to read information or also create and modify billing records.
  2. Open Settings > Security Settings > API Access in HostBill. Add a named access record with a useful description and appropriate status.
  3. Restrict the allowed IP address or subnet where practical. An empty restriction allows requests from any source address, subject to valid credentials.
  4. Set an expiry when appropriate for the integration's lifetime. Leave Undeletable off for routine credentials so they can be removed through the interface when retired.
  5. Generate the API ID and API Key. Review allowed methods immediately: HostBill documents all methods as initially enabled. Disable that broad selection and allow the specific functions the integration requires.
  6. Store the credentials in the integration's protected secret configuration. Use the API documentation and collection for the installed version, then test a permitted read operation before any write workflow.

02 Verify and operate the connection

Review the API Usage log for the expected function, API identity, caller address and result. Test that a disallowed function fails in a controlled environment. Establish how the integration reports errors and how its credentials will be rotated before expiry.

03 Example: test a read-only HostBill API method

Allow getHostBillversion for a test API identity and restrict it to your authorised caller. Replace the example HTTPS address with your HostBill API address. Store the API ID and key in private files outside the web root, each containing only its value with no trailing newline, readable only by the operator.

Command example
curl --fail --silent --show-error --request POST \
  'https://billing.example.com/admin/api.php' \
  --data-urlencode 'api_id@/private/path/hostbill-api-id' \
  --data-urlencode 'api_key@/private/path/hostbill-api-key' \
  --data-urlencode 'call=getHostBillversion'

This sends credentials in the POST body while leaving certificate verification enabled. Check the JSON response for success: true, the installed version and the expected API log entry. It should not create or alter a customer service.

Expected result: authentication, allowed method and caller restriction are verified with a documented read operation before enabling the integration's required write workflow.

Common questions

Why does an integration fail after moving servers?

Its outbound IP may no longer match the API access restriction. Verify the actual egress address and update the authorised restriction rather than opening access to every IP as a permanent workaround.

Can I share one unrestricted key among all scripts?

That makes ownership, logs and revocation harder to manage. Separate identities with narrow methods let you identify the failing caller and replace its credentials without changing every script.

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support