Request Detail Pages

This page-reference topic covers the service-request pages. The dedicated topics Requests To My Services and My Requests provide the broader inbox view.

Requests To My Services

Page Name

Requests To My Services

Purpose of the Page

Shows incoming service requests for the current user as a provider, allowing them to manage and respond to these requests.

Link to the Page

/service/requests

Conditions to Display

Authentication is required.
The stage router allows this page only for Paid users.

From Where It Is Accessed

The left-hand side menu.
The "View Requests To This Service" action on the Service Display page (visible to service owners).

Grid Filters and Actions

Service: Filters requests for a single service or shows all. The dropdown is populated from services matching the selected state and period.
State: Filters by status. Options are: pending, accepted, rejected, cancelled, user cancelled, expired, all. Defaults to "pending".
Period: Filters by time. Options are 1m, 3m, 6m, specific years from the current year back to 2026. Defaults to "1m".
Grid actions include Display, Messages, Respond, and Go To Session, with visibility depending on the request's state.

Changing a filter immediately reloads the visible list using the selected filters. The Filter button runs the same filtered reload explicitly, while the Refresh button clears the page cache for the current view and reloads the latest server data.

My Requests

Page Name

My Requests

Purpose of the Page

Shows outgoing service requests for the current user as a requestor, allowing them to track the status and take actions.

Link to the Page

/service/myrequests

Conditions to Display

Authentication is required.
The stage router allows this page only for Paid users.

From Where It Is Accessed

The left-hand side menu.
The "View My Requests For This Service" action on the Service Display page (visible to non-owners).

Grid Filters and Actions

Service, State, Period: Filtering options are identical to the "Requests To My Services" page.
Grid actions include Display, Copy, Messages, Cancel, and Go To Session, with visibility depending on the request's state.
The "Cancel" action is available for requests in the "pending" state and is performed via a POST request.

Service Request New

Page Name

Service Request New

Purpose of the Page

Creates a new service request for a specific service, or copies an existing request.

Link to the Page

/service/service_request_new?service_id=...&base_request_id=...

Conditions to Display

Authentication is required.
The stage router allows this page only for Paid users.
A valid service_id query parameter is required.
The user cannot request their own service.
The target service must be active and not deleted.

From Where It Is Accessed

The "Request This Service" action on the Service Display page.
The "Copy" action on the My Requests page, which passes a base_request_id to pre-fill the form.

Form Fields and Rules

Date: Required and must be a valid date.
Start Time: Required and must be on a 15-minute boundary (e.g., 09:00, 09:15, 09:30, 09:45).
Duration: Required, must be within that service's configured minimum and maximum session-hour limits (each limit is between 1 and 12).
Expiration: Required, must be between 1 and 1000 hours before the selected start time.
Balance Display: The top of the form shows your total balance, reserved hours, spendable now value, and the service's session-hour limits.
Duration Options: The dropdown only shows whole-hour values that satisfy both your spendable-now amount and the service's min/max session-hour limits.
Requested Mode: Required only when the service's mode is "any". The user must choose between "online" and "inperson".
Location Details: Required. For "inperson" requests, this should be a physical address. For "online" requests, it can be a meeting link or platform name.
Requestor Message: Optional, with a maximum length of 500 characters.
The backend performs additional validation, rejecting requests for past times, those that create scheduling overlaps, if the requestor has insufficient spendable hours, or if the provider has blocked the requestor.

Service Request Display

Page Name

Service Request Display

Purpose of the Page

Shows the details of a single service request in a read-only format, ensuring privacy between participants.

Link to the Page

/service/service_request_display?service_request_id=...&service_id=...

Conditions to Display

Authentication is required.
The stage router allows this page only for Paid users.
Both service_request_id and service_id query parameters are required.
The current user must be either the provider or the requestor for this specific request. Access is denied to all other users.

If a request detail, response, or message page says the request or message thread was not found, it can mean the record no longer exists, the link has stale or incomplete identifiers, or your account is not one of the participants authorized to view it.

From Where It Is Accessed

The "Display" action on the Requests To My Services grid.
The "Display" action on the My Requests grid.
A link from the Session Display page.

Information and Actions

Displays all key details: state, service title, provider/requestor names, start/end times, duration, mode, location, and all messages.
A "Go To Session" action appears only when the request is in the "accepted" state and has a corresponding session created (SessionId is present).
When the current user is the provider, the bottom action area also includes guidance for opening the requestor's public profile and blocking that user from future requests if needed.

Service Request Respond

Page Name

Service Request Respond

Purpose of the Page

Allows the provider to accept or reject a pending service request.

Link to the Page

/service/service_request_respond?service_request_id=...&service_id=...

Conditions to Display

Authentication is required.
The stage router allows this page only for Paid users.
Both service_request_id and service_id query parameters are required.
The current user must be the provider of the request.
The request's state must still be pending. If the request has been accepted, cancelled, or expired, this page will show an error.

From Where It Is Accessed

The "Respond" action on the Requests To My Services grid, which is visible only to the provider for pending requests.

Form Fields and Rules

Provider Response: Required. A radio button selection for "accepted" or "rejected".
Provider Message: Optional, with a maximum length of 500 characters.
Submitting the form calls the API to update the request state and then redirects the user back to the Service Request Display page.

Service Messages

Page Name

Service Messages

Purpose of the Page

Shows the message thread for a service request and allows participants to send new messages.

Link to the Page

/service/service_messages?from=...&service_request_id=...

Conditions to Display

Authentication is required.
The stage router allows this page only for Paid users.
A valid service_request_id query parameter is required.
The current user must be either the provider or the requestor for the request.
The from parameter (requests, myrequests, or sessions) controls the "Back" link's destination.
The conversation is still visible even after the request is cancelled, rejected, or expired, so members can review the history.
The new message form is shown only while the request is pending. After the request is accepted, messaging continues from the session pages while the session is scheduled or started.
If the other participant has blocked you, the conversation remains visible for history but the send form is removed and the page becomes read-only for new messages.

From Where It Is Accessed

The "Messages" action on the Requests To My Services grid.
The "Messages" action on the My Requests grid.
A link from session detail pages when the session originated from a request.

Information and Actions

Displays the full conversation history, including sender names, profile links, avatars, timestamps, and message text.
Provides a "Back" link to the originating page (request list or session).
Message: The new message text area is required and has a maximum length of 1000 characters. If messaging is not allowed for the current state, the page shows the thread in read-only mode.

When and how provider/requestor messaging works

Members can exchange messages while a service request is in the Pending state. After the request is accepted and becomes a session, messaging remains available while the session is Scheduled or Started.

When the request or session is later cancelled, rejected, completed, or expired, the conversation is still visible for reference, but the message form is hidden and the thread becomes read-only.

Where members can open the message thread

For Providers: From Requests To My Services or Sessions I Provide.
For Requestors: From My Requests or Sessions I Receive.
Detail Pages: From Service Request Display or Session Display.

How to see new messages

Unread conversations are highlighted on the Dashboard, so members can jump directly back into message threads.

Email notifications connected to request pages

New request email: Sent to the provider when a requestor creates a service request.
Response email: Sent to the requestor when the provider accepts or rejects the request.
Message email: Sent to the other participant when a new request-thread message is posted.
Expiry email: Sent to both participants if the request expires before response.
These emails point users back into the request and session pages when relevant.

Request editability and copy flow

Service requests are read-only after creation and cannot be edited in place. This keeps a single consistent version for both the requestor and the provider.

To make changes quickly, the requestor can use the Copy action from My Requests or from Service Request Display, then submit the copied request with updated values.

Automatic expiry before start time

When creating a request, the requestor chooses how many hours before the session start the request should expire.

If the provider does not respond before that configured expiration time, the system automatically expires the request and marks its state as expired.

When this happens, both the requestor and the provider receive an email notification about the expiry.

Time zone guidance

Dates and times shown on these request pages follow the current viewer's saved profile time zone. The date and time entered on Service Request New are also interpreted using the requestor's saved profile time zone, not the current device or browser time zone.

If you travel and want to use Solidarity in a new place, update your profile time zone first on Profile Edit so new requests and request displays match that local time.