Sessions Create API

1. API
2. v1
3. sessions
4. create
Check out List Item docs

Route

Responses

action-successful 200

This status indicates that the request was successful. If the request returns data, it can be found in the data key.

{"code": 200, "data": {}, "status": "action-successful", "message": "..."}

---

email-not-found 400

This status indicates that the email passed isn't recongized by our system.

{"code": 400, "status": "email-not-found", "message": "..."}

---

invalid-password 400

This status indicates that the password passed did not match the email passed.

{"code": 400, "status": "invalid-password", "message": "..."}

---

user-has-no-password 400

This status indicates that the user attempting to login manually has NULL or a blank password. This generally means that they registered with Google OAuth and there for will need to login using Google or Magic Link. Users can add a password if they want, but will need to login using the previously mentioned methods first.

{"code": 400, "status": "user-has-no-password", "message": "..."}

---

user-requires-role 400

This status indicates that the user requesting the session doesn't have a client, employee or liaison role. This would be the case if a user started, but didn't finish the registration processes.

{"code": 400, "status": "user-requires-role", "message": "..."}

---

client-required 401

This status is returned when the user makeing the request doesn't have a client, employee or liaison record. This means that they don't have any roles or permissions. Because we only allow our clients to register as a client, the user should be redirected to the PlanoAuth clients registration page where they can use the `/api/v1/users/client_register` API to register as a client. Eventhough the request will not be successful, this status will still return a `data` object because a session token is needed to register as a user.

{"code": 401, "data": {}, "status": "client-required", "message": "..."}

---

invalid-token 401

This status is returned when the authentication token passed is invalid.

{"code": 401, "status": "invalid-token", "message": "..."}

---

session-expired 401

This status is returned a session is older than seven days or hasn't been used in 72 hours. The user will need to reauthenticate. We allow our users to save a remember_me preference which will make there sessions last indefinitely.

{"code": 401, "status": "session-expired", "message": "..."}

---

missing-param 400

This status is returned when a required param was not passed with the request.

{"code": 400, "status": "missing-param", "message": "...", "missing_param": "email"}

---

invalid-param 400

This status is returned when a param was invalid when passed. For example, passing an id that doesn't exist or passing an invalid email address.

{"code": 400, "status": "invalid-param", "message": "...", "invalid_param": "email"}

---

application-crash 500

This status is returned when there is an internal server error. Please try again later.

{"code": 500, "errors": "...", "status": "application-crash", "message": "..."}

---

mandrill-email-failed 500

This status is returned when there was an issue using Mandrill to send an email. Any time this response is returned, there will be a notification in the production notifications tab so the dev team will be away of the failure. These errors will most likely correlate with a data issue and will need to be invesigated.

{"code": 500, "errors": "...", "status": "mandrill-email-failed", "message": "..."}

---

invalid-content-type 400

This status is returned if the request was made with the incorrect content-type so the request params could not be read. For more infromation on content-type, please refer to https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type.

{"code": 400, "status": "invalid-content-type", "message": "...", "content_type_passed": "application/json", "content_type_required": "text/plain"}

---

route-non-existent 500

Response returned when HTTP route does not exist.

{"code": 500, "status": "route-non-existent", "message": "..."}

---

Uncommon Responses

The responses below are not very common.

no-params-decoded Uncommon

This status is returned the request body was decoded, but no params where found.

{"code": 400, "status": "no-params-decoded", "message": "..."}

---

invalid-encoded-params Uncommon

This status is returned when the request body could not be decoded properly. This generally means that you are requesting a sensative_params API and your request body was not base64 encoded.

{"code": 400, "errors": "...", "status": "invalid-encoded-params"}

---

route-not-found Uncommon

This status is returned when the route record being requested hasn't been deployed yet.

{"code": 404, "path": "...", "status": "route-not-found", "message": "...", "http_method": "..."}

---

identify-request-error Uncommon

This status is returned when there is an internal server error before the route could be identified. Please try again later.

{"code": 500, "errors": "...", "status": "identify-request-error", "message": "..."}

---

service-not-found Uncommon

This status is returned when the route's API service record being requested hasn't been deployed yet.

{"code": 404, "status": "service-not-found", "message": "...", "route_id": "...", "api_service_key": "..."}

---