login
login allows you to seamlessly push your users through various projects - the idea is that each time you log a user into the front end of a project, you use login. When called, a token is created, and that token expires after the user is logged in successfully. Because tokens are assigned on a per project basis a user may be logged in simultaneously to multiple projects at once, and so each new project requires a new login token.
Name | Type | Required | Description |
action | string | true | login |
clogin_id | integer | true | This is a central login id which identifies a single user between any projects within your organization. |
group_id | integer | true | This designates which project the action should be applied towards. |
doc | array | true | doc should be an empty array. |
If you log in to the back end of the system and go to the admin management page, as soon as you click "invite admin," you are actually calling create and login. We use the API to create the admin in an internal system we use for admin billing. The key thing to notice is that you are still logged in as an admin while you are simultaneously logged in to our billing system; each login instance had its corresponding token.
Imagine your other application has a user who just generated some information, and you'd like to then push that user into Regpack to make the payment. Assuming you have some way to look up clogin_id for the user who starts in the other application, you would first use update in order to update any information you might need to update, and then use login to log the user in to the Regpack project. From there, they would have complete information (from update) and would be logged in to the project (from login), where they could proceed to make their payment. Additionally, you could combine this with other calls such as add_product in order to make sure their cart is correct prior to completing payment.
