Resource user activity

Inspect three stored activity indicators for a known email in one resource. Use this before choosing an identity flow; these flags do not authenticate the person.

Task	Operation
Inspect stored activity	POST /api/v1/check-user-activity

Example clients and synthetic values follow response conventions. Use WALLKIT_API_BASE for the supplied scheme and host, without /api/v1. Examples include the full path; Node.js examples use an ES module (.mjs).

Inspect stored user activity

POST /api/v1/check-user-activity

Find a user by normalized email, require their relationship with the selected resource, and inspect stored password, reset-mail and session records. This request consumes an IP-based activity counter before email validation. It neither signs in the person nor sends reset mail.

Before you call

Guest ACL permits this operation. Supply a valid resource public key; no user token or service key is needed for the guest example. A service-account credential does not automatically grant this guest action, because that role is separate. The email must already exist globally and have a relationship with this resource.

The activity counter is keyed by action, resource and resolved IP. Its threshold uses 50, but the first request initializes and increments the counter; there is no explicit time window in this helper. Do not promise a fixed 50-per-minute quota.

Request

JSON body with Content-Type: application/json.

Name	Location	Type / requirement	Meaning and constraints
resource	header	required public-key string	Selects the resource relationship and activity records.
email	JSON	required valid email string	Validated first, then email-filtered, trimmed and lowercased for global user lookup. No ownership proof.

A parsed JSON body that is empty or otherwise false in a boolean check fails before the counter. Missing or invalid email fails after the counter is consumed. Extra fields are not used by this action.

Result

HTTP 200 returns these booleans directly, without a user wrapper or timestamps.

Field	Type / presence	Meaning
has_user_resource_relationship_password	boolean; present	This resource relationship has a nonempty password field; not the global user password or proof of a valid credential.
is_sent_reset_password	boolean; present	A stored mail row exists for the user email, resource and reset event 199. No delivery, recency or completion proof.
is_exist_sessions	boolean; present	Any first matching user/resource session exists, or an archive row if none does. No active, expiry or current-login filter.

False means the corresponding inspected record/field was absent or empty. It does not mean the user was absent: missing user or resource relationship is an error. None of these flags proves consent, email verification, paid access or current sign-in.

Example: Choose a separate identity step

Inspect reader@example.com in the supplied resource. The result indicates a stored resource password and session history, with no matching reset-mail record.

curl -X POST "${WALLKIT_API_BASE}/api/v1/check-user-activity" \
  -H "resource: ${RESOURCE_KEY}" \
  -H "Content-Type: application/json" \
  --data-raw '{"email": "reader@example.com"}'

const response = await fetch(`${process.env.WALLKIT_API_BASE}/api/v1/check-user-activity`, {
  method: "POST",
  headers: {"resource": process.env.RESOURCE_KEY, "Content-Type": "application/json"},
  body: JSON.stringify({"email": "reader@example.com"})
});
console.log(response.status, await response.json());

import os, json
from urllib.request import Request, urlopen
from urllib.error import HTTPError

body = {'email': 'reader@example.com'}
request = Request(os.environ["WALLKIT_API_BASE"] + "/api/v1/check-user-activity",
    data=json.dumps(body).encode("utf-8"),
    headers={'resource': os.environ["RESOURCE_KEY"], 'Content-Type': "application/json"}, method="POST")
try:
    with urlopen(request) as response:
        print(response.status, json.load(response))
except HTTPError as error:
    print(error.code, json.load(error))

Synthetic HTTP 200 result:

{
  "has_user_resource_relationship_password": true,
  "is_sent_reset_password": false,
  "is_exist_sessions": true
}

Consequential alternate

An existing user/resource relationship can return all three flags false:

{
  "has_user_resource_relationship_password": false,
  "is_sent_reset_password": false,
  "is_exist_sessions": false
}

A globally unknown email instead returns HTTP 404, for example this synthetic error excerpt:

{
  "error": "user_not_found",
  "error_description": "User not found"
}

Handle missing identity separately from false activity flags.

Recovery

HTTP status	API code / shape	Cause	Next action
404	resource_not_exists	Resource key does not resolve.	Check the supplied resource key and context.
406	incorrect_data	Falsey or absent parsed JSON.	Send a JSON object with email and the correct media type.
406	requests_limit_exceeded	IP/resource/action counter reached its threshold.	Stop repeated lookups; ask the integration owner about configured counter lifetime. No reset time is promised.
409	invalid_email	Missing or invalid email; framework supplies the description.	Correct the email before another request.
404	user_not_found	No global normalized-email match.	Use the separate registration flow if appropriate; do not treat this as three false flags.
403	user_not_registered_in_resource	User exists without this resource relationship.	Confirm the selected resource and intended registration.
422	check_user_activity_error	Other caught lookup failure.	Retain the error context and ask the integration owner to inspect it.

Next task

Continue with ordinary identity for a separate sign-in, registration or reset task. A later content-access decision is still required before serving protected content.

See the Server-integrations (advanced) to select the actor, identifiers and next task.