regify Provider-SDK
- Why does regify provide a PROVIDER-SDK?
- The current state of this document
- regify PROVIDER-SDK API description
- Appendix
- Example
- Document history
Why does regify provide a PROVIDER-SDK?
The purpose of the regify PROVIDER-SDK
With its PROVIDER-SDK, regify gives its customers and other third parties a means to facilitate communication with the regify provider software and to enable integration into legacy systems.
Difference between the CLIENT-SDK and the PROVIDER-SDK
With both SDKs, regify opens up the capabilities of the regify solution to programmers who want to further enrich regify frontends or who want to integrate the regify solution into corporate business processes and legacy systems.
With the regify PROVIDER-SDK, regify gives their customers and other third parties a means to facilitate interaction with corporate applications.
With the regify CLIENT-SDK, regify gives their customers and other third parties a means to enrich the frontend communication.
The current state of this document
This document currently covers only some parts of the complete regify PROVIDER-SDK. You can see the parts in this chart:
function group | available |
---|---|
connection and login |
yes |
user-related |
yes |
regimail related |
yes |
regibox related |
yes |
transaction-related |
yes |
settings-related |
yes |
group-related |
yes |
SQL functions |
yes |
obligatory attachments related |
no |
representatives-related [1] |
no |
The regify PROVIDER-SDK is under continuous development and will get extended more and more in the near future.
regify PROVIDER-SDK API description
Conventions and rules
API calling conventions
The regify PROVIDER-SDK API uses HTTP calls and encodes function parameters in typical URL style. The main regify PROVIDER-SDK API is used in the following manner:
https://regifyportalurl/sdk.php?f=<function>
It will be followed by additional parameters of the called function. Additional parameters must be separated by the char „&“ like in other web standards. You need to use URL encoding standards to encode special chars where needed (like using url_encode() function in PHP). Alternatively, you may want to encode the values using base64 and use the optional parameters for base64 encoded values. Remember that base64 can use problematic chars, too. You should URL encode base64 strings, too („SGkgUGF0cmljay4=“ has to be transmitted „SGkgUGF0cmljay4%3D“)
It is necessary to use a https connection (SSL), because the PROVIDER-SDK will not permit usage without SSL encryption. |
Session-handling
The regify PROVIDER-SDK requires session-handling. Most HTTP functions that you can call are handling session-cookies, but not all. In order to prevent any problems in session-assignment, you must add the Session-Identifier (returned by the connect function) as a parameter to all further URLs you are calling. Don’t forget to separate the Session-Identifier with a „&“ from other parameters. Please refer to the example in this document.
Results
The results are encoded using a special scheme as follows:
Status|ReturnValue1|ReturnValueN
The divider is the PIPE (|) symbol ($2124). Status represents either „OK“ or „ERROR n“. „n“ represents the error-number. Error-numbers are described later in the „API error-codes“ chapter.
Please bear in mind, that the result may start using an UTF-8 BOM header (http://en.wikipedia.org/wiki/Byte-order_mark).
Super-User
The super-user is meant for complete access to the regify-provider functionality. It is intended for realizing functionality on the provider-side (not for customers). For example, a regify-provider can use this super-user to manage or extend functionalities.
Functions marked using the symbol are available in two versions:
The connected user is a normal user
The user is able to change data and use functions that only affect his own data. Using users other than his own will trigger error 11.
The connected user is a super-user
The user is able to manipulate and receive data from himself and all other users in the connected regify-provider instance. Even a super-user is only able to manipulate and retrieve user data of the same (sub)provider than himself. Super-Users are defined in the database by setting the „S“ flags in the users <Flags> column. You can achieve the super-user using your administration panel, too.
The group related functions are only available to super-users and group-master users. They do not work for normal users. |
Group-Master
The group-master is intended for customers of the regify-provider that want to enhance their regify group-management using regify provider-SDK functions (for example LDAP/AD synchronisation).
Functions marked using the
symbol
are available in two versions:
The connected user is a super-user:
The user is allowed to use this function with no restrictions.
The connected user is a group-master:
The user is generally able to use this function, but some functionality
may be restricted. Please read the function information to get further
information about possible restrictions.
The connected user is a normal user:
The user is not able to use this function.
Legend for function descriptions
Parameters and values in curly brackets are { optional }. Some parameters can get transmitted in plain text or base64 encoded:
n=<username> or nb=<username base64>
This means, that you can encode n=username or nb=dXNlcm5hbWU%3D.
Remember to url-encode even base64 text.
Some parameters may get transmitted using POST method. This is especially meant for greater data-amount. Please use POST for data with a size of more than 500 byte to prevent problems on proxies and caches.
Information about the grouping feature
In terms of regify, a normal regify account consists of one single user. Multiple email addresses can get assigned to one single user. Each user has his own premium-membership period and settings.
Multiple regify accounts can get grouped into a regify user-group. regify accounts can get assigned to a group or work unassigned. In case a regify account is assigned to a user-group, the premium-membership period is defined by the group settings and no longer by the individual regify account. All other user-data (like names, company name, address etc.) continue to belong to each single account.
The benefit of using user-groups is the possibility to allow basic administration to be managed by a group-administrator. Such functions are the creation of new passwords or to extend the premium-membership period for the whole group.

Additionally, a group offers the regify-provider ways to manage larger customers easily.
In case a customer wants to use the regify provider-SDK to manage his grouped accounts, you need to make one user of this group a group-master.
Login functions
connect
function | connect |
---|---|
parameters |
|
return values |
strStatus | strSessionSecret | strSessionIdentifier | strProviderNameB64 |
description |
Starts the connect and returns a session secret and session identifier. The returned provider-name is base64 encoded to avoid encoding issues. |
example |
sdk.php?f=connect |
login
function | login |
---|---|
parameters |
n=<username> or nb=<username base64> |
return values |
strStatus |
description |
Login the current user. |
example |
sdk.php?f=login&n=patrick@krustykrab.com&p=44ad05c6b7e702e79e88877ab53ad478cfa2d65a |
information |
The password is the sha1 hashcode of a string which is combined using
the hashcodes of „password“ and the session secret „bhz43bhufcsa4“ (see
connect function).
All hashcodes are encoded in hexadecimal format and are represented in lowercase. |
logout
function | logout |
---|---|
parameters |
|
return values |
strStatus |
description |
Logs off the current user and destroys the session. We recommend to use this function and do not let the session time out. |
example |
sdk.php?f=logout |
User related functions
useradd
function | useradd ![]() |
||
---|---|---|---|
parameters |
jb=<json userdata base64> or POST j=<json userdata> |
||
return values |
strStatus | intUserID |
||
description |
Adds a new user to the regify-provider. |
||
example |
sdk.php?f=useradd |
||
information |
Userdata-Dataset is encoded using JSON format, look into the userdata dataset for further information. If it is transferred in URL, the data must be encoded always using base64 (jb). The result returns the UserID of the newly created user. Function will fail with error 13 in case the UserName is already existing. UserName is deprecated! It is strongly recommended to not set UserName. In this case, the UserName is identical to the main email address. Please use it only for special purposes. |
||
important information: |
To add a new user, the userdata dataset does not need to contain all possible values. But some values are absolutely mandatory: PASSWORD, LASTNAME and MAILADDRESS
If no USERNAME is passed to the useradd function, the SDK will set username to the email address (which is the default anyway). |
userchange
function | userchange ![]() |
||
---|---|---|---|
parameters |
u=<userid> jb=<json userdata dataset base64> or POST j=<json userdata> |
||
return values |
strStatus |
||
description |
Changes userdata of an existing user. The userdata dataset does not need to be filled completely. It is possible to change only some special fields by only sending the desired fields. |
||
example |
sdk.php?f=userchange&u=1234&jb=eyJVc2VybmFtZSI6IlBhdHJp(…)IjowfQ==
|
||
information |
userdata dataset is encoded using JSON format. If it is transferred in URL, the data must be encoded always using base64. If you try to change the email address, ensure that the address is already assigned to this user.
If the user is authenticated, your data for REALNAME, TITLENAME, FIRSTNAME, LASTNAME and COMPANY will get ignored. You need to remove the authentication using userauthenticate first. Group-Administrator is not allowed to set SENDINGALLOWEDUNTIL, MAXTRANSACTIONS and SUBPROVIDERID. If a Group-Administrator is trying to set user flags S, I, G, D, B, P, A, O, they will be ignored. |
userdelete
function | userdelete ![]() |
---|---|
parameters |
u=<userid> or n=<username> or nb=<username base64> |
return values |
strStatus |
description |
Removes a user completely from the regify-provider. This function deletes the history, the email addresses, representatives and all other data of the user including owned regiboxes and their data. So use with care! |
example |
sdk.php?f=userdelete&u=1234 |
information: |
Please keep in mind, that deletion of a user generates clearing-traffic. Upon this, please do not delete and re-assign users to simply change some data. Use userchange function instead to change partial user-data. |
userget
function | userget ![]() |
---|---|
parameters |
u=<userid> or n=<username> or nb=<username base64> |
return values |
strStatus | userdata dataset (JSON Format) |
description |
Returns the complete data of a given userid. |
example |
sdk.php?f=userget&u=1234 |
information |
some fields like PASSWORD are not transmitted due to security reasons. |
usercheck
function | usercheck ![]() |
---|---|
parameters |
u=<userid> or n=<username> or nb=<username base64> |
return values |
strStatus | intUserID | intAuthenticated {| strPublicKey} |
description |
Returns security related information about a user. Returns ERROR 10 in case the user does not exist. |
example |
sdk.php?f=usercheck&u=1234 |
information |
intAuthenticated is 0=not authenticated or 1=authenticated. |
userinvite
function | userinvite |
---|---|
parameters |
parameters of invited person: parameters of inviting person: other parameters: |
return values |
strStatus | intUserID |
description |
Creates an invitation for the given user and returns the UserID of the new generated entry. An email will be sent to the user with instructions about how to activate the account and obtain an account password. You can add an optional invitation comment for individual use (i/ib). This comment will be inserted into the INVITATIONCOMMENT field of the invited user (table tbluser) and will not be visible to any people in the portal. If you do not set the un/unb parameter, the username will get generated by first trying to set its value to same value as the email. If that fails then, it will be generated using first name and last name. If a given username already exists, the username will get extended using a number (this does not trigger an error!). The optional parameter ia is only accepted, if in/inb and im/imb are given, too. Otherwise it will be ignored. In order to be able to invite a person using in/inb, im/imb, io/iob or ia parameter, the currently loggend-in user needs to own the INVITING-USER right or the SUPER-USER right (administration). Otherwise, this function returns error 20. The optional g parameter allows direct group association (if set != 0). For this to work, the inviting user has to own the SDK role "GROUP MASTER" and he needs to be assigned to a group. The invited user will then automatically get assigned to the same group like the currently regify account. This is independent of the given "parameters of inviting person" (like in/inb, im/imb, io/iob or ia). If the requirements are not given, this parameter triggers error 36. |
example |
sdk.php?f=userinvite&un=PatrickStar&m=patrick.star@bikinibottom.com&p=Mr.&fn=Patrick&ln=Star&c=DE&qb=SGkgUGF0cmljay4%3D |
information |
After calling this method, the newly generated user is not activated. To activate the account, the invited user needs to klick the link in his invitation email. If mobile phone number is given and provider supports SMS, the SMS process is executed (user needs to enter SMS code after clicking a link). The invitation comment is never shown to users. It allows technical classification or allocation of invited users. |
usergetlist
function | usergetlist | ||
---|---|---|---|
parameters |
{i=<filter string> or ib=<filter string base64>} |
||
return values |
strStatus | strUserList (JSON Format) |
||
description |
Returns a short JSON encoded array with some reduced user information about all available users of this provider. If you define the optional filter string, the function will only return users that match the filter string in their Username, RealName, Company or email address. The optional limit parameter defines, if you like to get only a reduced amount of results (numeric from 1 to n). If used, the result returns the most recent n users (highest UserIDs) at first (descending order).
|
||
example |
sdk.php?f=usergetlist&i=Crab |
||
information |
The returned group information is only a small subset containing GroupID, GroupName and GroupCode of the available groups. The JSON array is build like this (one user):
PHP decoding example:
|
usernewpassword
function | usernewpassword ![]() ![]() |
---|---|
parameters |
u=<userid> or |
return values |
strSuccess |
description |
Generates a new user-password and sends this to the given user. If the optional p/pb value is given (works only with super-user rights), it does not send a mail to the user. Super-user can reset the password of every user on the provider. The group-administrator can only reset the passwords of his group members. |
example |
sdk.php?f=usernewpassword&u=1234 sdk.php?f=usernewpassword&u=1234&p=myPasswd |
userauthenticate
function | userauthenticate | ||
---|---|---|---|
parameters |
user selection: authentication parameters: |
||
return values |
strStatus | strUnlockCode |
||
description |
Authenticates the given user.
setting of your provider AUTHTRANSMITURL value in provider-settings). strStatus may be „OK“ or an error with no unlock code. Only a user with super-user rights can authenticate users. |
||
example |
sdk.php?f=userauthenticate&u=765&t=1&l=5&c=example&r=0049172987654321 |
||
information |
The strUnlockCode will get returned only in case the return information (r) is not set or sending failed. If r is set, the strUnlockCode normaly returns empty and the unlock code will get transmitted to the authenticated person directly using the return information (in most cases SMS, if the provider offers such). If transmission failed, the unlock-code gets returned even if r has been set. Thus, in every case you receive an unlock-code as result, the user has not received it and it’s your job to transmit the unlock-code to the desired user! Setting an auth-level of 0 (zero) means to remove any authentication of this user. The user is no longer authenticated. Return information will get ignored.
|
Settings related functions
You can change user-related settings using this functions. Most of the settings can get changed and read by userget, userchange and usercheck functions, too.
If you do not own the super-user rights, you can only read and manipulate the settings of your own account.
usersetsettings
function | usersetsettings ![]() |
---|---|
parameters |
u=<userid> or |
return values |
strStatus |
description |
Changes one or more settings of the given user. The settings-values need to get transferred in a JSON encoded usersettings dataset using jb or POST[j]. |
example |
sdk.php?f=usersetsettings&u=1234&jb=eyJTRU5EUkVNSU5ERVJNQUlMIiA6IDB9 Info: this example sets {"SENDREMINDERMAIL" : 0} |
usergetsettings
function | usergetsettings ![]() |
---|---|
parameters |
u=<userid> or |
return values |
strStatus | strUserSettings (usersettings dataset JSON Format) |
description |
Returns the current settings of the given user. The setting are returned in JSON encoded format. Please refer to usersettings dataset for possible values. |
example |
sdk.php?f=usergetsettings&u=1234 |
Email related functions
mailadd
function | mailadd ![]() |
---|---|
parameters |
u=<userid> or |
return values |
strStatus {| strErrorAddresses } |
description |
Assigns one or more email addresses to the email addresses of the given user-id or username. If an email address already exists, no error will get returned as it will be recognized and handled correctly. To add multiple email addresses, divide them using semicolon or comma. In case of an error, the result is error 14 followed by a list of the failed email addresses. |
example |
sdk.php?f=mailadd&u=1234&m=patrick@bikinibottom.com;patrick@crabs.org |
information |
Parameter t allows two types of adding email addresses: The email addresses must be in correct SMTP format without any additional extensions like „Patrick Star <patrick@crabs.org>“, which would trigger an error 14. In case of an error, the error-number will be followed by a list of the email addresses that failed (divided by semicolon). If you use mb (b64 encoded email addresses), please encode the whole string of email addresses including divider (semicolon or comma). |
mailget
function | mailget ![]() |
---|---|
parameters |
u=<userid> or |
return values |
strStatus | strMailaddresses |
description |
Returns a list of all assigned email addresses of the given user. The email addresses are separated by semicolon. Email addresses that are not activated until now, will get returned in squared brackets. |
example |
sdk.php?f=mailget&u=1234 |
maildelete
function | maildelete ![]() |
||
---|---|---|---|
parameters |
u=<userid> or |
||
return values |
strStatus |
||
description |
Allows to dissolve the assignment of an email address to a user. If you like to delete more than one email address, divide email addresses using semicolon (;) or comma.
|
||
example |
sdk.php?f=maildelete&u=1234&m=patrick@crabs.org |
||
information: |
Please keep in mind, that deletion of an email address generates clearing-traffic. Upon this, please do not delete and re-assign email addresses to simply add one. Use mailadd function even if you do not know if the email address is already assigned or not. Already assigned email addresses will not trigger an error. This function does not trigger an error if the email address is not available at all. If you use mb (b64 encoded email addresses), please encode the whole string of email addresses including divider (semicolon or comma). |
mailcheckassignment
function | mailcheckassignment ![]() |
||||||||
---|---|---|---|---|---|---|---|---|---|
parameters |
m=<email addresses> or mb=<email addresses base64> |
||||||||
return values |
strStatus | strAssignedAddresses |
||||||||
description |
Allows to dissolve the assignment of an email address to a regify-account in the worldwide regify-network. If you like to check more than one email address, divide email addresses using semicolon (;) or comma. The function return strAssignedAddresses are the email addresses, that are assigned to the regify-network. The ones that are not assigned will not get returned. Multiple returned addresses are divided using semicolon. If you set the optional i parameter to a value greater than 0 (eg 1), the function ignores the clearing and checks only the local provider-database (check only local accounts). The default is to check the clearing, too. |
||||||||
example |
sdk.php?f=checkmailassignment&m=patrick@crabs.org,thaddeus@crabs.org |
||||||||
information: |
If you use mb (b64 encoded email addresses), please encode the whole string of email addresses including divider (semicolon or comma). |
Group related functions
All group related functions need a connected super-user. Normal users are not able to change any setting of groups.
groupadd
function | groupadd ![]() |
---|---|
parameters |
jb=<json groupdata dataset base64> or POST[json
groupdata] |
return values |
strStatus | intGroupID |
description |
Adds a new group to the regify-provider. |
example |
sdk.php?f=groupadd&jb=eyJVc2VybmFtZSI6IlBhdHJp(…)IjowfQ== |
information |
See the groupdata dataset for parameter reference. The GROUPNAME and GROUPADMINID are mandatory. A given GROUPID and SUBPROVIDERID will be ignored. Missing values will get a default value (even for the GROUPCODE Value). If you set the optional m parameter to 1, the system sends an email to the group administrator (defined by GROUPADMINID). This function uses template 19 to inform the group administrator about his group code and the current group values. To add users to the newly generated Group, please use groupadduser function. |
groupget
function | groupget ![]() |
---|---|
parameters |
n=<groupname> or nb=<groupname base64> or |
return values |
strStatus | groupdata dataset (JSON Format) |
description |
Returns all group data of the given group. |
example |
sdk.php?f=groupget&i=6 |
information |
Returns all group information about the given group. This does not return the assigned users. For this information, please refer to groupgetusers function. |
groupdelete
function | groupdelete ![]() |
---|---|
parameters |
n=<groupname> or nb=<groupname base64> or |
return values |
strStatus | intAffected |
description |
Deletes a group and returns the number of affected users. |
example |
sdk.php?f=groupdelete&i=6 |
information |
Deleting a group terminates the group membership of all assigned users. They will remain with active regify accounts but will no longer stay professional members. All unassigned users are falling back to private membership. intAffected returns the number of members that have been unsassigned by this function. This function does not send an email to the affected users (like groupremoveuser does). |
groupchange
function | groupchange ![]() |
---|---|
parameters |
n=<groupname> or nb=<groupname base64> or |
return values |
strStatus | intAffected |
description |
Changes group data and returns the number of affected users. The groupdata dataset does not need to be filled completely. It is possible to change only some special fields by only setting the desired fields. |
example |
sdk.php?f=groupchange&i=6&jb=eyJVc2VybmFtZSI6IlBhdHJp(…)IjowfQ== |
information |
The value intAffected is only greater 0, if some premium-date of users has been affected. This depends on the setting of the SETPREMIUMANYTIME provider-parameter and if the SENDINGALLOWEDUNTIL parameter has been set in this call (if not, returns allways 0). If you reduce the amount of MAXACCOUNTS lower as the number of currently assigned users, the users with the lowest activity will get removed first. If p is not set or 0, the affected users will get an email about removing them from the group. |
groupgetlist
function | groupgetlist ![]() |
---|---|
parameters |
{i=<filter string> or |
return values |
strStatus | strGroupList (JSON Format) |
description |
Returns a short JSON encoded array with some reduced group information about all available groups of this provider. If you define the optional filter string (i/ib), the function will only return groups that match the filter string in their GROUPNAME, GROUPCODE or SALESID. |
example |
sdk.php?f=groupgetlist&i=Crab |
information |
The returned group information is only a small subset containing GroupID, GroupName and GroupCode of the available groups. The JSON array is build like this (one group):
PHP decoding example:
|
groupgetusers
function | groupgetusers ![]() |
---|---|
parameters |
n=<groupname> or |
return values |
strStatus | strGroupUsers (JSON Format) |
description |
Returns a JSON encoded array with some reduced user information about the users assigned to this group. |
example |
sdk.php?f=groupgetusers&i=7 |
information |
The returned user information is only a small subset containing USERID, USERNAME, REALNAME and main MAILADDRESS of the assigned users. The JSON array is build like this (one user):
PHP decoding example:
Group-master users are only allowed to retrieve data of their own group. |
groupadduser
function | groupadduser ![]() |
---|---|
parameters |
n=<groupname> or nb=<groupname base64> or |
return values |
strStatus |
description |
Adds the user (only userid allowed) to the given group (i, n or nb). The assigned user will receive an email (template 17). If you set the optional p parameter to a value greater 0, the email will get suppressed (silent). |
example |
sdk.php?f=groupadduser&i=7&u=18 |
information |
If the maximum number of users in a group is already reached, this function returns error-code 19. If the given user is already assigned to the given group, the function returns „OK“, too. If SETPREMIUMANYTIME is TRUE, the premium-membership of the user will be the one of the group - no matter if it was previously a longer premium-period! If SETPREMIUMANYTIME is FALSE, a user will get the premium-length of the group only, if his actual premium-membership is shorter. If it is longer, this will remain untouched. Group-master users are only allowed to add users having the same mail-domain as the group-master itself. |
groupremoveuser
function | groupremoveuser ![]() |
---|---|
parameters |
u=<userid> |
return values |
strStatus |
description |
Removes the user (only userid allowed) from a group. The unassigned user will receive an email (template 18). If you set the optional p parameter to a value greater 0, the email will get suppressed (silent). If the user has not been assigned to a group, the function will return error-code 12. |
example |
sdk.php?f=groupremoveuser&u=18&p=1 |
information |
Unassigned (removed) users will get GROUPID = NULL and SENDINGALLOWEDUNTIL to a date of yesterday. So they will remain private member. Group-master users are only allowed to remove users from their own user-group. |
Transaction related functions
All transaction related functions are only accessing the transaction information of the currently loggend-in user. It is not possible to gather information about transactions that are not assigned to the currently loggend-in user.
gettransactionstate
function | gettransactionstate | ||
---|---|---|---|
parameters |
t=<transaction ID> |
||
return values |
strState | strFetchDate |
||
description |
Returns the state of the given transaction-id. If strState is 9, strFetchDate contains the fetching date in YYYY-MM-DD HH:MM:SS format. If strState is not 9, strFetchDate is empty. |
||
example |
sdk.php?f=gettransactionstate&t=9876543 |
||
information |
Returns the state of one given transaction-id. The following return values are possible: 0 = error or not found Please use gettransactionstatearray function to speed up if you like to check the state of a larger number of transactions.
|
gettransactionstatearray
function | gettransactionstatearray |
---|---|
parameters |
t=<list of comma seperated transaction ids> or tb=<list base64> or POST[t] |
return values |
strResult (JSON encoded array with transaction dataset data) |
description |
Returns the state of all given transaction-ids. The result is a JSON encoded array in transaction dataset format. Please submit the transaction-ids to request seperated by a comma. Please encode this using base64 for the tb parameter or submit it by using POST (t). Example: |
example |
sdk.php?f=gettransactionstatearray&t=9876543,9876544 |
information |
Returns the state of all given transaction-ids in an array that consists of transaction dataset entrys. If you use tb (b64 encoded transaction id’s), please encode the whole string of id’s including divider (comma). |
gettransactionlist
function | gettransactionlist | ||
---|---|---|---|
parameters |
{i=<filter> or ib=<filter base64>} |
||
return values |
strResult (JSON encoded array in transaction dataset format) |
||
description |
Returns the data of all transactions that match the filter and/or the date-range and/or the given state (numeric). If you set ds, you also have to set de - and vice versa. Using the optional l parameter (lowercase L), you can limit the number of results. As the result is sorted with the newest transactions at first, you always get the newest transactions on top. Possible state (s) values are only: Possible transaction types (t) are: |
||
example |
sdk.php?f=gettransactionlist&i=patrick |
||
information |
If you do not enter a time for ds or de, please keep in mind that this means 00:00:00 as time. So „2010-09-22“ means „2010-09-22 00:00:00“. Used as de, this will not display any transaction that has been started on 22. September. You can combine filter, date and state values together in one query (AND).
|
SQL functions
These functions need super-user rights in any case. Since these functions allow access to all databases, please use this with great care.
This function is only available for main provider users. A subprovider user is not able to use this function even if he owns super-user rights!
If you like to use this function, please contact regify support to get a list of all available tables, database-fields and their description.
sqlget
function | sqlget ![]() |
---|---|
parameters |
sb=<sql select base64> |
return values |
strStatus | strResult (JSON Format) |
description |
Returns the result of a given SQL select exactly like the database returns it. |
example |
sdk.php?f=sqlget&sb=U0VMRUNUIFVzZXJuYW1lIEZST00gdGJsdXNlciBXSEVSRSBVc2VySUQ9Nw== |
information |
This function allows only queries that begin with „SELECT “. It will not work if you use any keywords like UPDATE, DELETE etc. to prevent data curruption and missuses. In this case, the function will return error-code 12. Please have a look into your logfile to get more information about this error. This function encodes every returned value as string, even if it is only numeric. Upon this, a typical result for a select like
may return a result like this (remark the SUBPROVIDERID returned as string):
|
Appendix
userdata dataset
Userdata is encoded using the JSON standard (http://www.json.org/). As the complete regify-system operates using UTF-8 encoding, the returned values are UTF-8 encoded, too. The following values are used inside a JSON dataset for user-data:
Type [1] | Value | Description | Access [2] | ||
---|---|---|---|---|---|
N |
USERID |
The ID of the user (unique on the regify-provider). |
R |
||
S |
USERNAME |
The login username. |
RW |
||
S |
PASSWORD |
The uppercase sha1 hashcode of the user-password. This value is write-only and will not get returned by userget function. A regify-provider never stores the users password in plain text. There is only an encrypted hashcode available.
|
W |
||
D |
CREATIONDATE |
The date/time the user has been created. (local regify-provider time) [3] |
R |
||
D |
LASTACTIVITY |
The last date/time the user has been active. (local regify-provider time) [3] |
R |
||
S |
REALNAME |
The complete real name of the user. |
RW |
||
S |
FIRSTNAME |
The first name of the user. |
RW |
||
S |
LASTNAME |
The last name of the user. |
RW |
||
S |
TITLENAME |
Title (like Dr., Prof.). |
RW |
||
S |
COMPANY |
The organisation name of the user. |
RW |
||
S |
ADDRESS1 |
Address field 1. |
RW |
||
S |
ADDRESS2 |
Address field 2. |
RW |
||
S |
ZIPCODE |
Postal ZIP code. |
RW |
||
S |
CITY |
City name. |
RW |
||
S |
COUNTRY |
Country name in users language. |
R |
||
S |
IOC |
IOC country code. |
RW |
||
S |
MAILADDRESS |
The main email address for communication with the user. You can only change this value to an email address that is already assigned to the current user (affecting userchange function). While useradd function, this email address needs to be free. |
RW |
||
S |
PHONEMOBILE |
The mobile phone number of the user. |
RW |
||
N |
USERTYPE |
1 = Primary Member |
RW |
||
N |
ABO |
0 = no newsletter abonnement, |
RW |
||
N |
NEGOTIATOR |
Negotiator-Code number (not the code itself). |
RW |
||
S |
LANGUAGE |
Users language code („DE“ and „EN“). |
RW |
||
S |
FLAGS |
Different user-related flags: „E“ = enforced documents are available You can’t set the „S“ and „I“ flags without having super-user rights. Flags can get combined in random order (for example „XENR“). |
RW |
||
N |
AUTHENTIFICATED [4] |
0=not authenticated |
R |
||
D |
AUTHENTIFICATIONDATE [4] |
Date/time of the last successfully authentication. [3] |
R |
||
N |
AUTHLEVEL |
Level of authentication (0=no authentication, 1-10=level) |
R |
||
S |
PUBLICKEY |
If the user is authenticated (Authentificated=9), this field contains the public key in HEX encoded format (please refer regify-sdk documentation about the format of key in regify). |
R |
||
N |
KEYLENGTH |
Bitlength of the current Public-Key (eg 1024). |
R |
||
S |
KEYTYPE |
Algorithm of the currently used Public-Key („RSA“). |
R |
||
N |
RECIPIENTSNEEDAUTH |
0=recipients do not need to be authenticated (default) |
RW |
||
N |
SENDERNEEDAUTH |
0=user is able to open messages even from not authenticated users (default) |
RW |
||
D |
SENDINGALLOWEDUNTIL |
If this date is in the future, the member has a premium-account.
If this date is in the past, the member is a standard-member (can only read messages). This information is only used in regify community-provider setups. [3] |
RW |
||
N |
MAXTRANSACTIONS |
If set >0, this value overrides the MAXTRANSACTIONSPERMONTH setting of the provider. It offers the possibility to allow more transactions per month. The regify-provider will calculate the number of premium-accounts for this user in this way: Users=CEIL(MaxTransactions:MAXTRANSACTIONSPERMONTH) |
RW |
||
N |
MAXBOXSIZE |
If set >0, this value overrides the MAXBOXSIZE setting of the provider. It offers the possibility to allow a different box size for each user. Value is in Bytes! |
RW |
||
N |
CURRENTTRANSACTIONCOUNT |
The current regimail transaction-counter of this user. Only used if the transactions are not regimail mass sendings.
|
R |
||
N |
TRANSCOUNTREGIMAIL |
The current regimail mass transaction-counter of this user. Only used if the transactions are regimail mass sendings.
|
R |
||
N |
TRANSCOUNTREGIBILLSTANDARD |
The current regibill standard transaction-counter of this user.
|
R |
||
N |
TRANSCOUNTREGIBILLPREMIUM |
The current regibill premium transaction-counter of this user.
|
R |
||
N |
TRANSCOUNTREGIPAY |
The current regipay transaction-counter of this user in the last period.
|
R |
||
N |
TRANSCOUNTREGIBOX |
The number of regiboxes created in the last period. |
R |
||
N |
SUBPROVIDERID |
The assigned subprovider id of the user. While updating or adding a new user without setting a subprovider ID (or zero), the subprovider ID of the loggend-in user will get used.
|
RW |
||
N |
GROUPID |
ID of the group a user is assigned to. |
R |
||
S |
SALESID |
Optional ID to assign a salesman (for example). |
RW |
groupdata dataset
Groupdata is encoded using the JSON standard (http://www.json.org/). As the complete regify-system operates using UTF-8 encoding, the returned values are UTF-8 encoded, too. The following values are used inside a JSON dataset for group-data:
Type [1] | Value | Description | Access [2] |
---|---|---|---|
N |
GROUPID |
The ID of the group (unique on the regify-provider). |
R |
S |
GROUPNAME |
The name of the group. |
RW |
S |
GROUPCODE |
The code of this group. |
RW |
N |
GROUPADMINID |
The user ID of the group administrator. The group-administrator must be a member of the group itself. |
RW |
D |
DATECREATED |
Date the group was created. [3] |
R |
N |
MAXACCOUNTS |
Maximum number of accounts allowed in this group. |
RW |
D |
SENDINGALLOWEDUNTIL |
Until this date, the members of this group are premium members. [3] |
RW |
S |
SALESID |
Optional ID to assign a salesman (for example). |
RW |
usersettings dataset
Usersettings are encoded using the JSON standard (http://www.json.org/). As the complete regify-system operates using UTF-8 encoding, the returned values are UTF-8 encoded, too. The following values are used inside a JSON dataset for user settings:
Type [1] | Value | Description | Access [2] |
---|---|---|---|
N |
SENDREGISTEREDMAIL |
1=Send an email for each registered transaction |
RW |
N |
SENDRECEIPTMAIL |
1=Send an email for each delivered transaction |
RW |
N |
SENDREMINDERMAIL |
1=Send an email for each reminder exceeding |
RW |
N |
RECIPIENTSNEEDAUTHLEVEL |
The minimum authentification-level that is needed for recipients of the users transactions (valid only for new transactions). 0=no minimum authentication needed |
RW |
N |
SENDERSNEEDAUTHLEVEL |
The minimum authentification-level that a sender needs. If not reached, the message can not get opened by the user. 0=no minimum authentication needed |
RW |
N |
SHOWEXTENDEDPORTAL |
1 = Show extended portal functions |
RW |
N |
REGIBILL [4] |
1 = User is allowed to send regibills |
RW |
N |
REGIPAY [4] |
1 = User is allowed to send regipays |
RW |
N |
MASSREGIMAIL [4] |
1 = User is a mass sender (payed by
transactions) |
RW |
N |
REGIBOX [4] |
1 = User is allowed to create regiboxes |
RW |
transaction dataset
Transaction information is encoded using the JSON standard (http://www.json.org/). As the complete regify-system operates using UTF-8 encoding, the returned values are UTF-8 encoded, too. The following values are used inside a JSON dataset for transactions:
Type [1] | Value | Description | Access [2] |
---|---|---|---|
N |
TID |
The transaction id of the message. |
R |
S |
TYPE |
M=regimail |
R |
S |
SUBJECT |
The subject of the message (utf-8 encoded). |
R |
S |
RECIPIENT |
The recipient of the message (email address). |
R |
N |
STATE |
0=error or not found |
R |
D |
START |
The date the transaction has started by the sender. |
R |
D |
FETCHED |
The date the transaction has been fetched by the recipient. |
R |
API error-codes
The following chart gives an overview of possible error codes returned by the API functions in the format „ERROR n“:
code | description |
---|---|
10 |
Username/password wrong, user-id wrong or user not found. |
11 |
Function usage denied. You may need „Super-User“ rights to use this function. |
12 |
Parameters missing or having invalid values. |
13 |
USERID or USERNAME already given. Adding not possible. |
14 |
Assigning email address failed (already assigned to another user, wrong format or the maximum number of additional emails has been reached). |
15 |
Mandatory JSON data is missing (like USERNAME or MAILADDRESS for adding a new user or GROUPNAME for adding new groups etc.). |
16 |
It is not possible to assign this email address to this user. To assign a main-email address to a user, the email address needs to be already assigned using the mailadd function. |
17 |
There is not enough data to generate a valid username or some not allowed chars are used. |
18 |
Group not found (wrong group name or ID). |
19 |
Maximum number of users in the Group is reached. |
20 |
To be able to set invitationer-data, you need to be logged in as a user with the special „Inviting-User“ rights or as „Super-User“. |
21 |
The domain of the email address you wanted to invite is not valid (blacklisted by provider). |
22 |
Authentication error. Most time there are missing valid name or organization in user-profile. In case you are not able to find the error, please have a look at your regify-provider error log call support). |
23 |
You are not allowed to remove the main-email address of the user. |
24 |
You are not allowed to access this group. You are only allowed to manage your own group! |
25 |
A group-master can only add users to his group that are having the same email address-domain than the group-master itself. |
26 |
Currently, only authentication levels 0, 1, 3, 5, 7 and 9 are allowed. Authenticate levels greater than 3 require provider certification. |
27 |
You cannot delete this user because he is either a provider administrator or a group administrator. |
28 |
If the username is an email address, it is not allowed to be another one than the registered main email address. Use the same values for both username and main email address. |
29 |
Unable to send email. Maybe you verify if domain exists and if there are typos in there. |
30 |
The function to transmit the code is not available, because AUTHTRANSMITURL is not set. |
31 |
This feature is not supported by your regify provider (eg no SMS sending or other missing functionality settings). |
32 |
User did not provide a phone number, therefore he cannot receive security codes by SMS. This error can occur while trying to reset the password. |
33 |
This feature is not available to you. You may need to upgrade your account. |
34 |
No access from your IP allowed. Ask your regify provider to enable SDK usage from your IP address (Provider settings → Allowed IP-Ranges for Provider-SDK). |
35 |
Removing email address is denied because it is assigned as regibox owner for at least one regibox. |
36 |
You need GROUP MASTER SDK role and/or some group assignment in order to use this function or parameter. |
93 |
The account was locked due to possible misuse. Please try again in 10 minutes. |
94 |
Invalid JSON data (json decode failed). Please ensure, that you use UTF-8 encoding in your JSON values. You may check the JSON validity using http://www.jsonlint.com/, too. |
95 |
You need a SSL connection using HTTPS to be able to use the SDK. |
96 |
You need to be logged in to be able to use this function. |
97 |
Unknown function (remember: all function names are lowercase). |
98 |
Some undefined internal error occurred. Please contact support@regify.com. If you are a provider by yourself, please have a look into the php error log-file for possible reasons of failure. If you can not find the reason, please feel free to send us the error log-file content for further investigation. |
99 |
System in maintain-mode. No operation possible. |
Example
Here you can find an example of using the SDK in PHP 5. We assume, that you have a function GetURL() to get the content of a given https URL.
These are the functions we create to encapsulate the SDK access:
This is how we use these functions to gather all users which match „patrick“:
This function does a connect, followed by a login (hash-challenge) and requests a list of current providers users. Optionally, a filter may get used. This example offers only basic error handling. Please adapt to your own programming style and rules.
Document history
V1.0.5 - 17. December 2009
Added CurrentTransactionCount and SubProviderID to userdata dataset description.
Function userinvite has new options „invitation comment“ and „personal message“.
V1.0.6 - 20. January 2010
Function userinvite has new options „username“, „invitationer full name“ and „invitationer organisation name“ to optionally pre-assign such values to an invited user.
V1.0.7 - March 2010
User functions have a new function usergetlist to search and list users.
Eight new Group functions and group dataset definition have been added.
New function sqlget allows flexible retrieving of different provider-information (for example billing information).
Changed all long datatypes (lng) to integer (int).
Reorganized the structure of this document.
Added PHP example call.
V1.0.8 - March 2010
Added limit-option to usergetlist function.
The connect function returns the base64 encoded providername, too.
V1.0.9 - April 2010
Updated documentation, because all JSON encoded data is now allways UPPERCASE!
Group function groupadd allows a missing GROUPCODE value and offers the option to inform the group administrator by email.
Function userinvite has new options „invitationer email address“ and „invitationer authentication-level“.
V1.0.10 - May 2010
Added special user flag „I“, needed for invitations with fake sender in userinvite function. Added associated error-code 20.
V1.1.0 - July 2010
Added settings-related functions (to change user-settings).
Added transaction-related functions (to access transaction information).
Added user-authentication function userauthenticate.
V1.1.1 – September 2010
Added additional JSON validation (triggers new error number 94 in case of invalid JSON).
V1.1.2 – October 2010
The provider-SDK now respects the GROUP-MASTER role of logged in users. The affected functions are groupget, groupgetusers, groupadduser, groupremoveuser, userchange, userget, usernewpassword, mailadd, mailget and maildelete.
Actualized the PHP example with better structure.
V1.1.3 – March 2011
Added function mailcheckassignment which allows to check the assignment of a email address against the regify-network.
V1.1.4 – July 2011
Enhanced userinvite function by adding mobile phone number and a new passwordtype.
Fixed some layout issues.
V3.1.0 – December 2011
New error code 30.
The SDK version is now the same than the underlying provider version. This makes, sense, because the SDK functionality is changing in the same intervals as the provider.
V3.2.2 – January 2012
Added SALESID field to user-data json set.
V3.4 – September 2013
Added p/pb parameter and changed behavior to usernewpassword function.
Added t parameter to gettransactionlist function.
Added TYPE value to transaction dataset.
Added REGIBILL, REGIPAY and MASSREGIMAIL to usersettings dataset.
Updated FLAGS in userdata dataset.
Added SDK error code 31.
Fixed problems with uppercase email addresses in some SDK functions.
Fixed example for usergetsettings function.
New error codes 26 and 27.
V3.5 – April 2014
Updated FLAGS description in userdata dataset.
Added CHATALLOWEDUNTIL value to userdata dataset.
Added transaction type C (regichat protocol) to description of gettransactionlist and json parameters.
Added some more password information about password characters, length and encoding.
V4.0 – January 2015
Updated FLAGS description in userdata dataset.
Added missing PHONEMOBILE parameter in userdata dataset.
Added regichat admin parameter to usersetsettings, usergetsettings and usersettings dataset.
Added transaction type X (regibox invitation) to description of gettransactionlist and json parameters.
Updated regify company logo.
V4.0.2 – July 2015
Updated FLAGS description in userdata dataset.
Updated userchange desciprion.
usercheck function now needs super-user rights.
Added regibox functionality to usersettings dataset.
V4.0.10 – November 2016
Updated FLAGS description in userdata dataset regarding “H” flag.
V4.1.0 – April 2017
Updated document version. API is unchanged.
V5.0 – June 2018
Added startchat function and startchat dataset.
Function useradd no longer needs REALNAME as a mandatory parameter.
Added error number 29 (error while sending email).
Added error number 34 (accessing from invalid IP).
Added error number 93 (The account was locked due to possible misuse).
V5.1 – July 2020
Function maildelete was enhanced for error handling. Function description was updated.
Added error number 35 (email address is used as regibox owner).
V5.2 – December 2021
The regichat product was completely removed from regify provider V5.2! |
Removed startchat function.
Removed startchat dataset description. Added deprecated marks to several regichat related fields and values.
Added parameter g to userinvite function.
Added error code 36 (You need GROUP MASTER SDK role and/or some group assignment).
Conversion of this document to asciidoc format.