These notes are new for v3.2 and the content will change.
This is currently in FAQ format, because the topics seem to be Frequently Asked Questions.
Over time, notes will also be added to individual function pages.
If you would like to help with this process, please visit the forum, and add your comments to this thread
which has been created for this purpose.
Thank you for your patience and collaboration.
Create a "Remote" User in the ISPConfig UI. Check boxes there to assign permissions for the kinds of queries that can be processed by that user.
Almost all API queries require a session_id. To get that, call the login function, sending the remote username and password. The response will be a single value which will be used as your session ID for a limited time period for all other requests.
Finishing with a logout request is recommended, but optional since the session IDs expire.
"The api is largely just an interface to the database tables, and will usually accept what you send, whether that's consistent/correct or not. It can be a feature, eg. you can create a mail alias first before creating the mailbox to which it forwards, but it does mean you have a lot more testing to do on your side because you can't just rely on an error to be thrown if you send inconsistent data."
These fields are referenced often in the developer forum and in code, usually with some confusion. These internal database fields are used in SQL queries to determine parent/child client relationships. The fields are not passed to API calls, with the exception of one function, client_get_id which is a convenience function to return the client_id for a sys_userid. In the past other functions included these keys in the request. Now, when a function request includes a client_id, at query time a lookup is done to get the internal sys_userid for that client.
The sys_userid can identify the creator of a record. This may be the ID of the local/UI user or the remote/API user that is logging in to create records. If a client record is created without a reseller, both the sys_userid and the sys_groupid are the same user ID.
If a client record is created with a reseller, the meaning of the fields is completely different. The sys_userid is not a logged-in user ID. It is a new ID that represents the client under the reseller. The sys_groupid for a client under a reseller is (a foreign-key to) the sys_userid of the client record for the reseller. In this scenario, the sys_groupid establishes a child-to-parent relationship.